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CHAPTER  1 


Introduction 


1.1.  Introduction 

Many  of  today’s  computing  applications  have  performance  requirements  that  cannot  be  fully 
satisfied  by  von  Neumann  architectures  which  are  based  on  the  control  flow  model  of  computa¬ 
tion.  Two  examples  of  these  applications  are  the  weather  problem  [DENN84]  and  logic  program¬ 
ming  [BIC84].  Algorithms  used  in  these  applications  have  a  high  degree  of  parallelism  which  can¬ 
not  be  efficiently  executed  on  the  von  Neumann  computer.  Thus,  alternative  models,  such  as  the 
data-driven  model  of  computation,  have  been  of  increasing  interest  to  researchers.  The  dataflow 
model  of  computation  addresses  the  performance  requirements  of  computing  applications,  such  as 
the  weather  problem,  by  exploiting  the  parallelism  within  algorithms  used  for  solving  problems 
within  the  application  area.  Languages  and  architectures  which  make  use  of  the  dataflow  model 
of  computation  are  thus  desirable  for  use  on  these  applications. 

1.2.  Motivations 

Several  converging  technologies  have  reached  the  point  where  they  can  be  integrated  and 
used  to  develop  an  advanced  programming  environment  for  writing  parallel  programs.  These 
technologies  include  advanced  graphics  workstations,  models  of  computation  which  can  be  used 
for  parallel  computation,  and  parallel  architectures.  A  programming  tool  to  experiment  with  a 
dataflow  language  which  supports  the  simultaneous  existence  of  textual  and  graphical  representa¬ 
tions  for  programs  could  be  beneficial  to  programmers  writing  parallel  programs.  In  this  thesis,  a 
dataflow  language  which  supports  the  simultaneous  existence  of  textual  and  graphical  representa¬ 
tions  for  programs  is  proposed. 


Several  manufacturers  are  providing  commercially  available  parallel  processing  computers 
with  potential  for  satisfying  the  performance  requirements  of  many  of  today’s  computing  prob¬ 
lems.  Unfortunately,  these  computers  usually  do  not  have  adequate,  user-friendly  programming 
environments.  In  addition,  as  Ahuja,  Carriero,  and  Gelernter  [AHUJ86]  state,  ”as  parallel 
machines  emerge  commercially,  there  has  been  little  effort  spent  on  making  high-level,  machine- 
independent  tools  available  on  them.  Young  debutante  machines  are  sometimes  gotten-up  in 
their  own  full-blown  parallel  languages;  more  often  they  come  dressed  in  only  a  handful  of 
idiosyncratic  system  calls  that  support  the  local  variant  of  message-passing  or  memory-sharing”. 
The  programming  environments  and  the  primitives  they  support  are  different  for  each  parallel 
machine.  Programs  which  run  on  one  machine  may  need  to  be  totally  recoded  to  be  executed  on 
another  machine.  Thus,  there  is  a  need  for  a  more  general,  user-friendly  programming  tool.  A 
programming  tool  should  also  be  portable  so  that  it  could  be  used  by  more  than  one  parallel  com¬ 
puter. 

Several  alternative  models  of  computation,  including  the  control  flow  and  dataflow  models, 
have  been  explored  to  discover  each  model’s  potential  use  in  parallel  programming.  A  brief  dis¬ 
cussion  of  the  dataflow  model  and  its  advantages  will  be  given  later.  Several  high-level,  textual 
languages  and  graphical  base  language  notations  have  been  developed  for  experimentation  with 
parallel  programming.  Because  many  dataflow  languages  use  a  graphical  base  language,  a  map¬ 
ping  between  the  textual  languages  and  graphical  base  languages  is  possible.  [RAED85]  has  given 
several  reasons  for  the  use  of  graphical  representations  of  programs.  These  reasons  include  the 
potential  for  faster  transfer  rate  of  knowledge  using  graphics  and  the  random  access  of  informa¬ 
tion  from  graphical  representations.  A  dataflow  language  which  supports  the  simultaneous 
existence  of  graphical  and  textual  representations  for  programs  should  be  beneficial  to  program¬ 
mers  because,  at  each  step  of  program  development,  a  programmer  could  choose  to  write  using 
the  type  of  representation  that  is  most  convenient  for  writing  that  part  of  the  program. 


Widespread  use  of  graphical  languages  has  been  constrained  by  the  absence  of  graphics  tech¬ 
nology  needed  to  implement  graphical  languages.  The  potential  to  use  graphical  representations 
for  programs  has  become  practical  with  recent  advances  in  interactive  graphics  technology. 
Several  graphics  workstations,  which  support  useful  primitives  that  can  be  utilized  within  a 
graphical  programming  language,  have  been  developed  and  made  commercially  available. 

In  this  thesis  we  propose  that  a  dataflow  language  which  utilizes  both  graphical  and  textual 
representations  for  programs  be  made  available  for  use  in  parallel  programming.  The  features  of 
a  prototype  language  are  synthesized  from  existing  textual  languages.  The  graphical  representa¬ 
tions  of  the  language  are  incorporated  from  existing  graphical  base  languages,  as  well  as  other 
graphical  representations  (e.g.,  Nassi-Shneiderman  diagrams  [NASS73]). 

1.3.  Overview 

Most  existing  programming  languages  and  architectures  are  based  on  the  traditional  (fetch- 
execute-store)  control  flow  model  of  computation.  In  the  control  flow  model,  operations  are  exe¬ 
cuted  in  an  explicit  order  determined  by  a  control  mechanism  used  by  a  programmer.  Programs 
written  in  control  flow  languages  are  represented  by  a  sequence  of  operations'  consisting  of  an 
operator  and  its  necessary  operands.  The  programmer  is  totally  responsible  for  explicitly  specify¬ 
ing  the  order  of  the  operations  in  a  program.  Data  is  passed  between  operations  by  the  use  of 
variables  which  denote  memory  locations  in  a  shared  memory.  When  an  assignment  is  made  in  a 
program,  the  data  in  the  memory  is  changed  as  is  the  global  state  of  execution.  The  control  flow 
model  is  implicitly  sequential  in  nature.  Parallelism  can  be  introduced  only  after  studying  the 
operations  in  a  program  and  discovering  which  can  be  performed  in  parallel.  Explicit  control 
structures  (i.e.,  FORK  -  JOIN)  must  be  used  to  specify  which  operations  are  to  be  performed  in 
parallel.  Thus,  the  control  flow  model  of  computation  can  introduce  parallelism  in  programs,  but 
the  control  information  and  program  structures  needed  can  become  excessive.  Backus  [BACK78 

1  In  this  thesis,  an  operation  refers  to  a  program  instruction  which  consists  of  one  operator  ami  one  or  more 
operands.  The  operations  include  any  arithmetic,  boolean,  and  data-dependent  operations. 


describes  many  problems  that  plague  control  flow  languages.  These  include  the  language’s  “gross 
size,  complexity,  inflexibility,  and  lack  of  useful  mathematical  properties”  [BACK78], 

The  dataflow  model  of  computation  relieves  the  programmer’s  burdensome  task  of  specify¬ 
ing  parallelism  in  programs  by  utilizing  an  alternative  representation  for  computation.  The 
dataflow  model  does  not  utilize  a  shared  memory  or  a  locus  of  control  mechanism,  and  is  not  his¬ 
tory  sensitive.  In  the  dataflow  model,  operations  are  executed  in  an  order  determined  by  the  data 
dependencies  of  a  program,  not  by  an  explicit  control  mechanism.  A  programmer  does  not  expli¬ 
citly  specify  the  ordering  of  operations  in  a  program,  only  the  data  dependencies  of  the  opera¬ 
tions.  Dataflow  programs  are  conveniently  described  in  terms  of  a  directed  graph.  The  nodes  of 
the  graph  represent  operations  or  actors  that  produce  result  tokens  by  performing  transformations 
or  tests  on  input  tokens.  The  arcs,  which  connect  the  nodes  of  the  graph,  are  used  to  carry  data 
values  in  the  form  of  tokens.  These  tokens  flow  along  the  arcs  in  a  specified  direction  from  one 
node  to  successor  nodes.  Thus,  the  arcs  define  the  data  dependencies  between  the  operations. 
The  basic  dataflow  model  states  that  a  node  is  enabled  when  all  input  arcs  hold  data  values  and 
the  output  arcs  are  empty.2  An  enabled  node  is  executed  or  fired  by  removing  a  token  from  each 
input  arc,  performing  the  specified  transformation  on  the  input  tokens,  and  producing  one  or  more 
result  tokens.  An  example  of  a  dataflow  program,  which  was  taken  from  [LAND81]  is  shown  in 
Figure  1.1.  The  program  computes  the  factorial  of  N.  The  model  also  does  not  maintain  a  global 
execution  state.  Instead  a  local  state  is  maintained  which  consists  of  the  executing  operation  and 
its  successors. 

The  dataflow  model  is  implicitly  concurrent  in  nature.  Instructions  which  require  a  data 
value  must  wait  for  the  instruction  that  produces  the  value  to  fire.  The  sequencing  constraints 
and  the  execution  order  of  the  operations  are  determined  by  the  data  dependencies. 

s  Different  forma  of  this  basic  model  have  been  proposed  and  are  discussed  in  |LAND81|. 


1.4.  Review  of  Related  Research 


The  fundamental  concepts  upon  which  the  dataflow  model  of  computation  are  based  upon 
are  described  in  (KARP69,  DENN74,  ARVI78,  SHRI80,  TREL82,  and  SHAR85],  Several  research 
efforts  [KARP69,  RODR69,  ADAM68,  DENN74,  KOSI73,  ARVI78,  and  DAVI78]  have  resulted  in 
alternative  models  of  computation  which  share  the  same  basic  principles.  Landry  [LAND81] 
presents  an  overview  of  these  and  other  models.  Several  novel  architectures  [GURD85,  DENN80] 
and  applicative  languages  [ACKE79,  HANK81,  and  ARVI78]  have  been  developed  in  association 
with  the  different  models.  An  overview  of  the  architectures  appears  in  [TREL82  and  SRIN86). 
The  language  proposed  in  this  thesis  is  based  on  Val,  Id,  and  Lucid  which  are  summarized  in  Sec¬ 
tion  2.2. 

Formal  specification  of  dataflow  languages  has  received  limitied  attention  by  researchers. 
McGraw  [MCGR82]  discusses  two  formal  specifications  of  Val.  The  first  specification,  presented 
by  Gehani  and  Wetherall,  who  gave  a  complete  denotational  specification  of  Val.  The  second 
specification,  presented  by  Ackerman,  who  gave  an  axiomatic  specification  of  a  “Val-like  toy 
language”.  Brock  [BROC78]  gives  an  operational  specification  of  a  subset  of  Val.  Brock’s 
specification  utilizes  a  translation  algorithm  to  map  program  constructs  into  a  corresponding 
graph  and  a  semantic  function  to  map  the  graph  into  formal  semantics. 

Raeder  [RAED85]  presents  an  excellent  overview  of  the  research  in  visual  programming  and 
gives  several  reasons  for  the  emergence  of  visual  programming3.  Visual  programming  is  concerned 
with  the  creation,  manipulation,  and/or  execution  of  programs  in  a  graphical  form.  Graphical  pro¬ 
gramming  uses  an  arrangement  (picture)  of  graphical  icons  to  represent  a  program.  The  picture  is 
then  translated  into  machine  instructions  using  a  strict  mapping  mechanism. 

Brooks  [BR0087]  presents  several  reasons  why  “nothing  even  convincing,  much  less  excit¬ 
ing,  has  emerged”  from  visual  programming  efforts.  These  reasons  include  that  graphical 

*  One  of  three  major  areas  of  visual  programming  as  defined  by  |GRAF85|  is  the  development  of  graphics-based, 
very  high-level  programming  languages. 


representations  used  to  describe  conventional  software,  such  as  the  flowchart,  are  a  very  poor 
abstraction  of  the  software;  and  that  software  is  very  difficult  to  graphically  visualize.  Brooks  was 
mainly  concerned  with  conventional  software,  not  dataflow  programs  which  can  be  naturally 
represented  using  either  a  graphical  or  textual  representation.  Textual  dataflow  programs  are 
translated  into  graphical  representations.  Thus,  graphical  representations  are  not  a  poor,  but  a 
natural  abstraction  of  their  textual  equivalents.  Graphical  representations  of  dataflow  programs 
are  also  not  hard  to  visualize;  in  fact,  the  graphical  representations  show  the  parallelism  within 
dataflow  programs. 

Few  high-level  graphical  languages  have  been  developed.  Pagan  [PAGA87]  presents  a  pro¬ 
gramming  environment  for  an  FP-like  language  which  has  a  graphical  syntax.  The  language, 
which  is  a  modified  subset  of  Backus’  FP,  uses  a  graphical  syntax  similar  to  Nassi-Shneiderman 
diagrams.  A  program  is  depicted  by  nested  boxes.  Matwin  and  Pietrzykowski  [MATW85]  present 
a  functional  language,  PROGRAPH,  with  semantics  which  are  based  on  the  dataflow  model.  Pro¬ 
grams  are  expressed  in  the  form  of  pictographs.  Graphical  representations  are  presented  for  con¬ 
ditionals,  loops,  user-defined  functions,  parallel  computation  operators,  and  an  apply  operator. 

1.5.  Statement  of  the  Problem 

This  thesis  contains  a  description  of  a  dataflow  language,  PDL4,  that  supports  the  simul¬ 
taneous  existence  of  graphical  and  textual  representations  for  programs,  and  the  formal 
specification  of  the  syntax,  graphical  representation,  and  semantics  of  the  language.  Several  exist¬ 
ing  textual  dataflow  languages  have  been  studied  and  features  of  these  languages  were  selected  to 
synthesize  the  nucleus  for  the  new  language.  A  description  technique,  which  utilizes  three 
specification  techniques,  was  developed  to  specify  the  graphical  representation,  textual  syntax, 
and  semantics  of  the  language.  A  new  graphical  data  type  and  a  complete  axiomatic  specification 
are  presented. 


4  PDL  denotes  the  Prototype  Dataflow  Language. 


1.8.  Synopsis  of  Thesis 


In  Chapter  2,  an  overview  of  the  textual  dataflow  programming  languages  in  use  today  is 
presented.  The  features  and  programming  constructs  of  each  language  are  explained.  Several 
graphical  base  languages  associated  with  existing  dataflow  models  are  also  presented. 

In  Chapter  3,  an  overview  of  the  specification  techniques  used  to  specify  PDL  is  provided. 
The  techniques  include  the  axiomatic  and  algebraic  specification  techniques  and  BNF  Grammar. 

In  Chapter  4,  an  informal  discussion  of  the  prototype  dataflow  programming  language,  PDL, 
developed  in  the  thesis  work  is  presented.  Specific  language  features,  which  were  synthesized 
from  the  languages  described  in  Chapter  2,  are  discussed  in  terms  of  both  their  textual  and  graph¬ 
ical  representations. 

In  Chapter  5,  the  formal  specification  of  the  prototype  language  is  given.  A  specification  for 
the  textual  syntax,  graphical  representation,  and  semantics  of  each  language  construct  is  given 
using  the  techniques  introduced  in  Chapter  3. 

In  Chapter  6,  conclusions  and  suggestions  for  future  research  are  given. 


CHAPTER  2 


Dataflow  Languages 


2.1.  Introduction 

A  dataflow  program  is  represented  by  a  directed  graph  composed  of  nodes  connected  by 
arcs.  The  nodes  of  the  dataflow  graph  represent  individual  operations  (instructions)  which 
receive,  perform  transformations  upon,  and  transmit  data  tokens.  The  tokens  flow  along  the  arcs 
from  the  producer  of  the  token  to  the  consumer.  Hence,  the  arcs  define  the  data  dependencies  in 
the  dataflow  program.  Since  a  dataflow  system  performs  its  operations  asynchronously,  with  each 
node  firing  when  all  of  its  input  tokens  are  available,  several  operations  can  be  performed  con¬ 
currently.  Hence,  dataflow  languages  can  represent  parallelism  in  a  natural  manner. 

Most  dataflow  languages  developed  to  date  [ACKE79,  ARV178,  and  HANK81]  use  a  textual 
representation  for  programs.  Several  researchers  have  proposed  alternative  dataflow  models  which 
have  as  their  basis  a  graphical  notation  for  programs.  In  Section  2.2,  several  relevant  properties 
of  dataflow  languages  are  discussed.  In  Section  2.3,  several  graphical  notations  for  programs  pro¬ 
posed  by  Dennis  [DENN74],  Rumbaugh  [RUMB77],  and  Kosinski  [KOSI73]  are  discussed.  In  Sec¬ 
tion  2.4,  three  predominant  languages,  Val,  Id,  and  Lucid,  currently  being  used  for  dataflow  pro¬ 
gramming  research,  are  described.  Other  textual  languages,  some  of  which  were  patterned  after 
Val,  Id,  and  Lucid  are  also  discussed. 

2.2.  Language  Issues 

Several  relevant  properties  of  dataflow  languages  are  discussed  in  [ACKE82,  SHAR85,  and 
HAN85].  Most  dataflow  languages  exhibit  some,  but  not  necessarily  all  of  these  properties.  Six 
relevant  properties  of  dataflow  programming  languages  are  identified  by  Ackerman  [ACKE82]  and 
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Sharp  (SHAR85).  These  include  freedom  from  side  effects,  locality  of  effect,  equivalence  of  instruc¬ 
tion  scheduling  constraints  with  data  dependencies,  a  “single-assignment”  convention,  an  unusual 
notation  for  iteration,  and  a  lack  of  history  sensitivity  in  procedures. 

Side  effects  arise  in  programs  through  the  use  of  global  variables  and  by  reference  parameter 
transmission.  Global  variables  and  by  reference  parameter  transmission  are  not  present  in  a 
dataflow  programs.  Further,  dataflow  languages  utilize  a  value-oriented  programming  philosophy 
rather  than  a  variable-oriented  philosophy.  All  identifiers  of  a  program,  including  data  structures, 
denote  values  rather  than  memory  locations.  [GAUD86]  discusses  several  solutions  for  the  treat¬ 
ment  of  structured  values. 

Locality  of  effect  implies  that  instructions  do  not  have  far  reaching  data  dependencies.  The 
effect  that  the  instructions  have  is  restricted  to  the  block  of  code  in  which  the  instructions  appear. 
Identifiers  used  .n  a  program  are  active  only  within  their  defining  block  and  have  no  effect  beyond 
that  block. 

In  a  sequential  language,  instruction  scheduling  is  determined  by  the  order  in  which  instruc¬ 
tions  are  listed.  However,  in  a  dataflow  programming  language,  the  order  of  execution  is  deter¬ 
mined  by  the  data  dependencies  of  the  program.  Therefore,  the  instruction  scheduling  constraints 
are  equivalent  to  the  data  dependencies  of  the  instructions.  Instruction  scheduling  constraints 
and  data  dependencies  must  be  equivalent  so  that  the  instruction  firing  rule  holds.  Freedom  from 
side  effects  and  locality  of  effect  assure  that  the  scheduling  constraints  and  data  dependencies  of  a 
program  are  equivalent. 

The  single  assignment  convention  states  that  “a  variable  may  appear  on  the  left  side  of  an 
assignment  statement  once  within  the  area  of  the  program  in  which  it  is  active”  [ACKE82].  The 
assignment  binds  the  identifier  on  the  left  side  to  the  value  on  the  right.  An  example  of  the  single 
assignment  convention  and  the  violation  of  this  convention  are  show  in  Figure  2.1.  Each  identifier 
in  the  block  of  code,  except  J.  is  assigned  once  and  used  only  after  it  has  been  assigned.  Identifier 
J  violates  the  single  assignment  convention  because  J  appears  on  the  right  side  of  the  assignment 
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S:=X  +  Y; 
D:=3*S; 
E:=S/2  +  F(S); 
J:=J+1; 


Figure  2.1  -  considerations  for  the  single  assignment  convention 


statement  before  it  is  bound  to  a  value  (J  may  not  appear  on  both  sides  on  an  assignment  state¬ 
ment). 

Dataflow  languages  use  a  different  notation  for  iteration  than  that  used  in  conventional  con¬ 
trol  flow  languages.  The  need  for  a  new  notation  is  caused  by  the  fact  that  side  effects  and  pro¬ 
gram  state  information  are  absent  from  dataflow  languages.  Loops  have  four  distinct  parts:  ini¬ 
tialization,  a  test  for  loop  completion,  the  redefinition  of  loop  variables,  and  the  production  of 
result  values.  Special  operators  are  used  to  redefine  the  values  of  the  loop  variables  between  each 
iteration  of  a  loop.  Redefinition  of  the  loop  variables  occurs  only  at  the  loop  boundaries.  In  Val, 
redefinitions  are  allowed  to  occur  only  after  the  word  »fer.  An  example  of  Val’s  notation  for  itera¬ 
tion  is  shown  in  Figure  2.2.  The  values  of  K  and  J  on  the  left  and  right  sides  of  the  assignment 
refer  to  different  identifiers.  The  identifiers  on  the  left  side  refer  to  the  values  of  the  identifiers  on 
the  next  iteration  of  a  loop.  The  identifiers  on  the  right  side  refer  to  the  values  on  the  current 
iteration  of  the  loop.  Therefore,  the  single  assignment  convention  is  still  enforced  during  each 

for  J,K:=  N,l;  do 
if  J  =  0  then  K 
else  iter  J:=J-1; 
iter  K:=K*J; 

end 

end 

Figure  2.2-  example  of  Val’s  notation  for  iteration 


cycle  of  the  loop.  If  the  values  of  loop  variables  depend  upon  the  values  of  those  variables  in  pre¬ 
vious  cycles,  a  sequential  iterative  loop  must  be  used.  If  the  values  are  not  dependent  on  each 
other,  some  form  of  a  parallel  loop,  such  as  Val’s  FORALL  loop  [ACKE79],  can  be  used. 

The  lack  of  history  sensitivity  means  that  the  value  of  the  output  of  each  procedure  is 
dependent  only  on  its  current  input  values5.  The  procedure  cannot  remember  past  input  values. 
The  lack  of  history  sensitivity  means  that  the  languages  are  functional  in  nature.  Each  node  of  a 
dataflow  program  represents  a  true  mathematical  function  in  that  the  output  produced  is  only 
dependent  upon  the  input  it  receives.  In  Lucid,  arbitrarily  long  streams  and  special  operations 
are  used  to  achieve  history  sensitivity.  For  example,  Lucid’s  first  operation  remembers  the  first 
element  in  an  input  stream  and  produces  a  stream  of  tokens,  each  of  which  has  the  value  of  the 
first  input  token. 

The  dataflow  languages  Val  and  Id  exhibit  all  of  the  properties  discussed.  Lucid,  which  was 
not  developed  for  dataflow  programming,  can  be  used  for  dataflow  programming  because  the 
language  exhibits  many  of  the  above  cited  properties. 

2.3.  Graphical  Languages 

A  dataflow  program  maybe  represented  by  a  directed  program  graph.  The  nodes  of  the 
graph  represent  either  arithmetic,  logical,  or  run-time,  decision-making  operations.  The  arcs 
represent  the  flow  of  data  in  the  form  of  tokens  from  the  producer  to  the  consumer  of  the  token. 
Individual  operations  may  be  combined  to  form  complex  functions  and  finally  program  graphs. 
Three  graphical,  base  languages  [DENN74,  RUMB77,  and  KOSI73]  have  been  studied  and  are 
now  briefly  discussed. 

2.3.1.  Dennis'  Language 

Dennis  [DENN74]  presents  a  graphical  base  language  into  which  Val  programs  can  be 
translated.  The  language  has  two  types  of  nodes,  links  and  actors.  Links  are  used  to  produce 


Streams  and  operations  to  manipulate  streams  may  be  introduced  to  achieve  history  sensitivity. 


multiple  copies  of  a  data  token.  Two  types  of  links  are  used,  one  for  data  values  and  one  for  con¬ 
trol  values.  Eight  actors  are  used,  an  operation  actor  (for  all  functions),  a  decider  actor  which 
produces  control  values,  a  true  gate,  a  false  gate,  a  merge  actor,  and  three  boolean  actors  (and, 
or,  and  not)  which  act  upon  control  values.  The  merge,  true-gate,  and  false-gate  nodes  are  used 
for  run-time  data-dependent  decisions  to  affect  the  flow  of  data  tokens.  These  nodes  are  used  to 
implement  the  graphical  base  language  equivalents  of  high  level  program  constructs.  A  node  can 
execute  only  when  all  input  arcs  have  tokens  present  and  the  output  arcs  are  empty.  Dennis’ 
language  allows  for  cyclic  graphs,  so  a  token-tagging  scheme  is  introduced  to  distinguish  tokens  of 
different  cycles  of  a  procedure.  An  explicit  application  node,  the  apply  node,  is  used  to  perform  a 
run-time  binding  of  an  argument  list  to  a  named  procedure.  Rumbaugh’s  language  [RUMB77]  is 
similar  to  Dennis’  except  that  only  two  data-dependent  decision  nodes  are  used,  the  merge  and 
switch. 

2.3.2.  Kosinski’s  Language 

Kosinski  (KOSI73,  KOS73b]  presents  a  dataflow  programming  language  designed  for  use  in 
operating  systems  programming.  Programs  in  the  language  are  composed  of  function  definitions 
which  are  based  on  a  set  of  programming  primitives.  Programs  are  determinate  in  nature  unless 
indeterminacy  is  explicitly  introduced.  The  language  uses  two  types  of  nodes,  computational  and 
administrative.  The  computational  nodes  include  constants,  predicates,  and  the  typical  arith¬ 
metic,  boolean,  and  string  operations.  Administrative  nodes  include  forks,  switches,  function 
applicators,  and  several  loop  nodes.  The  inbound  and  outbound  switch  nodes  are  used  to  imple¬ 
ment  the  base  language  equivalent  of  the  if  and  for  constructs  of  high-level  dataflow  languages. 
Loop  nodes  are  used  to  implement  the  different  types  of  loops  present  in  high  level  languages.  The 
loop  node  also  introduces  a  memory  structure  in  programs.  Forks  are  used  to  replicate  data 
tokens  of  any  type.  Function  applicators  are  similar  to  Dennis’  apply  node.  Kosinski  allows  any 
sub-graph  to  be  named  and  used  as  a  function  (the  sub-graph  is  replaced  by  a  single  node  in  the 
graph).  Operations  can  execute  with  partial  inputs,  and  can  take  more  than  one  input  token  from 
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the  same  arc.  The  arcs  carry  not  only  data  values,  but  PRESENCE  and  DONE  signals.  These 
signals  are  used  for  operation  synchronization.  Kosinski’s  inbound  and  outbound  switches  are 
incorporated  into  the  design  of  PDL  to  implement  the  base  language  equivalent  of  PDL’s  program 
constructs. 

The  success  of  graphical  languages  has  been  impeded  by  the  lack  of  adequate,  user-friendly 
graphical  programming  tools.  Therefore,  dataflow  researchers  have  given  limited  attention  to 
graphical  languages  and  have  concentrated  on  developing  several  high  level  textual  programming 
languages  to  support  research  efforts. 

2.4.  Textual  Languages 

In  this  section,  some  high  level  textual  programming  languages  are  presented.  Val 
[ACKE79]  and  Id  [ARVI78],  are  applicative  languages  that  have  been  developed  by  Jack  Dennis' 
group  at  MIT  and  the  Arvind  group  at  the  University  of  California  at  Irvine,  respectively.  Since 
Val  and  Id  are  similar,  they  will  be  discussed  together.  The  biggest  difference  in  the  languages  is 
the  type  of  dataflow  model  the  languages  use.  Lucid  [WADG85],  was  not  developed  for,  but  is 
currently  being  used  for,  dataflow  programming.  Several  example  programs  and  a  discussion  of 
each  of  the  language’s  features  are  given  in  the  following  sub-sections.  These  three  languages 
were  used  as  a  foundation  for  developing  PDL  which  is  introduced  in  Chapter  4. 

2.4.1.  Val  and  Id 

Val  [ACKE79,MCGR82]  and  Id  [ARVI78„\RVI80j  were  designed  for  highly  concurrent 
numerical  applications.  Since  the  languages  are  applicative,  they  exhibit  many  of  the  properties 
discussed  in  Section  2.2.  The  languages  are  free  from  side  effects,  have  locality  of  effect,  use  a  sin¬ 
gle  assignment  convention,  and  utilize  completely  functional,  block-structured  features. 

Since  the  languages  are  functional  in  nature,  all  functions  or  operations  compute  specific 
output  values  depending  upon  the  input  given  to  the  module  or  operation.  The  functionality  of 
the  languages  guarantees  that  side  effects  do  not  occur.  .Although  the  languages  are  similar  in 


their  features,  they  are  based  on  entirely  different  models.  Val  is  based  on  a  static  model  and  its 
features  exhibit  static  behavior.  In  a  static  model,  only  one  occurrence  of  an  node  (instruction)  is 
enabled  for  firing  at  one  time.  Concurrent  invocations  of  an  instruction  are  not  permitted. 
Instructions  are  loaded  into  memory  before  computation  begins.  The  static  model  also  allows 
only  one  token  can  reside  on  an  arc  at  one  time.  Id  is  based  on  a  dynamic  model  and  most  of  its 
features  exhibit  dynamic  behavior.  In  a  dynamic  model,  several  instances  of  a  node  can  be  exe¬ 
cuting  concurrently  and  more  than  one  token  may  reside  on  an  arc  at  one  time.  The  instances  of 
a  node  can  be  dynamically  generated  at  run-time.  Id  tags  data  elements  to  isolate  data  elements 
for  each  instance  of  a  node  and  assigns  an  activity  name  with  each  instance  of  a  node.  The 
instance  and  its  set  of  input  data  tokens  must  have  the  same  names  for  the  instance  to  fire.  Id 
uses  several  special  operators  and  the  Unfolding  Interpreter  [ARVI82]  to  manipulate  the  tags  and 
activity  names. 

Val  was  designed  to  meet  two  design  goals:  implicit  concurrency  and  ease  of  program  con¬ 
struction.  Most  concurrency  in  Val  is  implicit,  but  the  language  also  supports  one  explicit  form  of 
concurrency,  the  FORALL  loop.  An  Id  programmer  relies  on  the  Unfolding  Interpreter  to  dis¬ 
cover  the  concurrency  in  programs  and  generate  several  independent  activities  which  can  execute 
concurrently. 

A  VAL  program  is  composed  of  a  number  of  function  modules.  An  example  of  a  Val  pro¬ 
gram  module  which  performs  quicksort  is  shown  in  Figure  2.3.  The  code  has  not  been  syntacti¬ 
cally  verified.  The  example  is  presented  only  to  show  some  of  Val's  program  constructs.  Each 
function  module  consists  of  a  header,  optional  type  definitions,  and  a  result  expression.  Function 
modules  are  called  by  using  the  name  of  the  module  with  a  list  of  actual  parameters.  Function 
definitions  may  not  be  passed  as  parameters  to  a  function  module. 

A  program  in  Id  is  a  list  of  expressions.  An  example  of  an  Id  program  which  performs 
quicksort  is  shown  in  Figure  2.4.  This  example  is  taken  from  [CARL85;.  Type  definitions  are  not 
utilized  by  Id;  rather  the  identifier  type  is  inferred  from  the  context  in  which  the  identifier  is 
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********* ****************************************************************************** 
Procedure  quicksort  receives  an  array  of  elements  and  the  size  of  the  array,  and  produces  a  sorted 
array.  The  procedure  uses  two  other  procedures;  one  (qsortl)  to  produce  two  other  sorted  arrays 
(Above  and  Below)  and  one  (qsort2)  to  merge  the  elements  of  the  two  sorted  arrays  and  a  pivot 
element  (A[n/2])  into  one  sorted  array. 

********************* ******* ******** ********* ****** ****** ************ ****************** 

1  procedure  quicksort(a:array(int],n:integer;  returns  array  [integer]) 

2  below.array  [integer]  ,j  rinteger, above  :array  [integer]  :=qsortl(a,n/2,n); 

3  qsort2(below,j, above, a[n/2],n) 

4  end 

*************************************************************************************** 
Procedure  qsortl  is  used  to  divide  an  array  (a)  into  two  arrays  (above  and  below)  and  either  re¬ 
turn  these  arrays  (if  the  size  of  the  array  is  one),  or  return  the  array  produced  by  recursively  cal¬ 
ling  quicksort  on  these  arrays  (line  8).  The  two  arrays  are  formed  by  testing  each  element  of  the 
input  array  to  see  if  the  element  is  less  than  or  equal  to  the  pivot  element  a[m]  (line  10).  If  the 
element  is  less  than  or  equal  to  the  pivot  element,  the  element  is  appended  to  array  below  and  the 
index  of  this  array  (j)  is  incremented  (line  11).  Otherwise,  the  element  is  appended  to  array 
above  and  its  index  (k)  is  incremented  (line  13).  This  process  occurs  for  each  element  in  the  input 
array  (a)  (lines  6-16).  In  line  6  of  the  program,  the  arrays  (above  and  below)  are  initialized  (both 
are  empty  arrays)  and  the  indices  of  the  arrays  are  set  to  zero. 

* * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * ** * ** * ** 

5  procedure  qsortl(a:array[integer],m,n:integer;  returns  array  [integer),  integer,  array  [integer]) 

6  for  i:integer:=l;  below, above:array[integer]:empty[integer];  j,k:integer:=0,0  do 

7  if  i  >  n  then 

8  if  j  >  1  then  quicksort(below,j)  else  below,  j,  if  j  >  1  then  quicksort(above,k)  else  above; 

9  elseif  i  <  >  m  then 

10  if  a[i]  <=  a[m]  then 

11  iter  below:=below[j+l:a[i]];  j:=j+l 

12  else 

13  iter  above:=above[k+l:a[i]];  k:=k+l 

14  endif 

15  endif 

16  endfor 

17  end 

*************************************************************************************** 
Procedure  qsort2  merges  two  arrays  (below  and  above)  and  the  pivot  element  (mid)  by  appending 
the  pivot  element  and  each  element  of  array  above  onto  array  below  to  form  the  sorted  array. 
*************************************************************************************** 

19  procedure  qsort2(below:array [integer],  j:integer,  above:array[integer],mid:integer,n:integer; 

20  returns  array  [integer]) 

21  for  i:integer:=j+2;  sorted:array[integer]:=below[j  +  l:mid]  do 

22  if  i  >  n  then  sorted 

23  else 

24  itersorted:=  sorted[i:above[i-j-l]] 

25  endif 

26  endfor 

27  end 

Figure  2.3-  quicksort  written  in  Val 


*> 


17 


************************************************************************************** 

Procedure  quicksort  receives  an  array  of  elements  and  the  size  of  the  array,  and  produces  a  sorted 
array.  The  procedure  uses  two  other  procedures;  one  (qsortl)  to  produce  two  other  sorted  arrays 
(Above  and  Below)  and  one  (qsort2)  to  merge  the  elements  of  the  two  sorted  arrays  and  a  pivot 
element  (A[mj)  into  one  sorted  array. 

************************************************************************************** 

1  procedure  quicksort(A.n) 

2  (m  «—  n/2; 

3  below,  j,  Above  «—  qsortl(A,  m,  n); 

4  return  qsort2(Below,  j,  Above,  A[m],  n); 

5  ) 

************************************************************************************** 

Procedure  qsortl  is  used  to  divide  an  array  (A)  into  two  arrays  (Above  and  Below)  and  either  re¬ 
turn  these  arrays  (if  the  size  of  the  array  is  one),  or  returning  the  array  produced  by  recursively 
calling  quicksort  on  these  arrays  (lines  16-18).  The  two  arrays  are  formed  by  testing  each  element 
of  the  input  array  to  see  if  the  element  is  less  than  or  equal  to  the  pivot  element  A[m]  (line  11). 
If  the  element  is  less  than  or  equal  to  the  pivot  element,  the  element  is  appended  to  array  Below 
and  the  index  of  this  array  (j)  is  incremented  (line  12).  Otherwise,  the  element  is  appended  to  ar¬ 
ray  Above  and  its  index  (k)  is  incremented  (line  13).  This  process  occurs  for  each  element  in  the 
input  array  (A)  (lines  9-15).  In  lines  7  and  8  of  the  program,  the  arrays  (Above  and  Below)  are  in¬ 
itialized  (both  are  empty  arrays)  and  the  indexs  of  the  arrays  are  set  to  zero. 
************************************************************************************** 

6  procedure  qsortl(A,  m,  n) 

7  (initial  Below  <—  A;  j-* — 0; 

8  initial  Above  <—  A;  k«— 0 

9  for  i  from  1  to  n  do 

10  (  if  i  ^  m  then 

11  (*/  A.[i]  <  A[m]  then 

12  new  Below<—  append(Below,  j+1,  A[i]);  j«— j  +  1; 

13  else  new  Above«— append( Above,  k+1,  A[i]);  k«— k+1; 

14  ) 

15  ) 

16  return  (if  j  >  1  then  quicksort(Below,j)  else  Below), 

17  j. 

18  (t/k  >  1  then  quicksort  Above,  k)  else  Above) 

19  ) 

************************************************************************************** 

Procedure  qsort2  merges  two  arrays  (Below  and  Above)  and  the  pivot  element  mid  by  appending 
the  pivot  element  and  each  element  of  array  Above  onto  array  Below  to  form  the  sorted  array 
(sorted). 

************************************************************************************** 

20  procedure  qsort2(Below,  j,  Above,  mid,  n) 

21  (  initial  sorted*—  append(Below,  j+1,  mid); 

22  for  i  from  j+2  to  n  do 

23  new  sorted*—  append(sorted,  i,  Above[i-j-l]); 

24  return  sorted 

25  ) 


Figure  2.4  -  quicksort  written  in  Id 
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used.  Procedures  may  be  passed  as  parameters  to  other  procedures.  Val’s  function  modules  and 
Id’s  procedures  behave  like  true  mathematical  functions:  they  compute  a  specific  output  value  for 
a  given  input  value.  Thus,  the  languages  are  not  history  sensitive,  although  history  sensitivity  is 
introduced  in  Id  through  the  use  of  streams  and  feedback  loops. 

Val  and  Id  utilize  expressions  and  values  as  the  basic  units  of  computation.  All  language 
constructs  are  expressions  which  can  return  several  values.  The  basic  expressions  include  con¬ 
stants,  value  names,  and  the  basic  mathematical  and  logical  operations  applied  to  other  expres¬ 
sions.  Both  languages  support  the  same  basic  scalar  data  types  and  operations,  and  use  a  value- 
oriented  programming  philosophy. 

Val’s  scalar  types  include  boolean,  integer,  real,  and  character.  Three  types  of  structures 
are  used:  the  array,  the  record,  and  the  oneof.  Type  oneof  allow  discriminated  union  data  types 
and  is  discussed  in  Section  4.2.1.  Val  allows  the  definition  and  use  of  constructed  types.  Val  uses 
an  extensive  error  handling  system  which  associates  error  values  with  each  data  type,  and  exten¬ 
sive  type  checking  rules  to  check  for  correctly  typed  arguments  to  each  operation  and  function. 
The  error  handling  system  simplifies  the  treatment  of  errors  in  programs  by  allowing  errors  to 
propagate.  Thus,  computation  is  allowed  to  continue  after  an  error  arises. 

Values  associated  with  identifiers  in  Id  are  typed,  not  the  identifiers  themselves.  Identifiers 
can  assume  values  of  any  type.  There  are  ten  types  of  Id  values  which  include  integer,  real, 
boolean,  string,  structure,  procedure  definition,  manager  definition,  manager  object,  programmer- 
defined  data  types,  and  error  data  types.  A  structure  value  is  either  an  empty  structure  or  a  set 
of  < selector: value  >  ordered  pairs.  Resource  manager  definitions  and  objects  allow  Id  to  be  used 
for  operating  systems  programming. 

The  compound  constructs  supported  by  Val  include  the  begin  construct,  the  if  construct,  the 
tagease  construct,  the  for-iter  construct,  and  the  forall  construct.  Figure  2.1  shows  the  use  of  the 
begin,  if,  and  for-iter  constructs.  An  example  of  the  forall  construct  is  shown  in  Figure  2.5.  The 
example  produces  four  results,  one  integer  and  three  arrays.  The  forall  construct  is  explained  in 


Chapter  4. 


Id  supports  similar  program  expressions.  Four  basic  expressions  which  include  blocks,  condi¬ 
tionals,  loops,  and  procedure  applications  are  utilized  by  Id.  Block  expressions  are  similar  to  Val’s 
begin  construct.  Conditional  expressions  are  similar  to  the  if  construct  of  Val.  If  the  result  of  one 
iteration  of  a  loop  expression  does  not  depend  upon  previous  iterations,  the  loop  expression  can  be 
unraveled  into  concurrent  executions.  The  unraveled  loop  is  similar  to  the  forall  construct  of  Val. 
Both  Val  and  Id  use  a  different  notation  for  loops  than  is  used  in  conventional  languages.  An 
explicit  operator  is  used  to  update  the  values  of  identifiers  between  iterations  of  a  loop.  Id’s  pro¬ 
cedure  applications  have  been  incorporated  into  the  design  of  PDL  and  are  explained  in  Chapter 
4. 


2.4.2.  Lucid 

Lucid  [ASHC76,  ASHC77,  and  WADG85]  is  a  functional  programming  language  in  which 
dataflow  programs  can  be  written.  The  use  of  Lucid  for  dataflow  programming  is  justified  by  two 
features  of  the  language.  One,  the  language  has  no  side  effects;  and  two,  the  sequence  of  opera¬ 
tions  is  determined  by  the  data  dependencies  within  a  program.  The  order  of  statements  in  a  pro¬ 
gram  is  irrelevant. 

Lucid  is  also  a  formal  system  in  which  dataflow  programs  can  be  written  and  proofs  of  the 
programs  can  be  deduced.  Using  the  formal  system,  proofs  of  Lucid  programs  are  derived  directly 


forall  J  in  [l,N] 

X:  re  al : = squ  are_roo  t(  re  al(  J ) ) ; 
eval  plus  J*J 
construct  J,X,X+1.0 
end 

Figure  2.5  -  example  of  Val's  forall  loop 
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from  the  program  text  using  logical  reasoning.  Lucid  has  a  number  of  special-purpose  functions 
which  are  used  within  a  program.  These  special-purpose  functions,  called  filters,  require  extra 
axioms  and  rules  in  order  to  prove  Lucid  programs. 

A  program  written  in  Lucid  can  be  thought  of  (operationally)  as  infinitely  reading  a  stream 
of  input  values,  performing  computation  upon  these  values,  and  producing  another  stream  of 
result  values.  Lucid  programs  are  composed  of  functions,  where  clauses,  and  a  number  of  condi¬ 
tional  expressions.  The  conditional  expressions  utilized  by  Lucid  include  the  if  expression,  the 
ease  expression,  and  the  eond  expression.  The  where  clause  is  the  block  structuring  mechanism  of 
the  language.  The  if  expression  is  similar  to  the  conditional  constructs  of  Val  and  Id.  The  rase 
and  eond  expressions  provide  an  alternative  way  of  writing  nested  if  expressions.  An  example  of  a 
Lucid  program  which  performs  quicksort  is  shown  in  Figure  2.6.  The  example  is  taken  from 
[WADG85], 

Identifiers  in  Lucid  programs  denote  arbitrarily  long  sequences  of  data  entities  called  his¬ 
tories.  Lucid  program  statements  are  considered  to  be  true  mathematical  assertions  about  the 
histories  of  these  identifiers.  The  end  of  a  sequence  is  denoted  by  a  special  eod  marker. 

Lucid  is  “typeless”  in  the  sense  that  no  syntactical  type  checking  is  performed  and  there  are 
no  type  declarations.  The  language  does  support  data  types  though,  including  integer,  real, 
boolean,  word,  character  strings,  and  finite  lists.  The  language  uses  the  special  object  error  to 
denote  a  stream  of  error  values.  Each  data  type  has  operations,  called  filters,  associated  with  it. 
These  filters  or  operations  behave  the  same  as  operations  in  most  dataflow  programming 
languages,  except  that  filters  perform  pointwise  computation  on  streams  of  data  values.  Pointwise 
filters  compute  one  output  token  set  for  each  input  token  set. 

Lucid  has  a  number  of  special  filters  used  to  build  streams  and  extract  elements  from 
streams  to  produce  new  streams.  These  filters  can  be  pointwise  or  non-pointwise  in  their  opera¬ 
tion.  Non-pointwise  filters  can  have  some  internal  memory  associated  with  them  and  can  main¬ 
tain  their  identities  between  each  token  set.  Non-pointwise  filters  need  not  produce  an  output 


21 


************************************************************************************** 

Procedure  quicksort  accepts  a  stream  of  data  values  and  produces  either  a  stream  with  one  ele¬ 
ment  or  a  stream  which  is  formed  by  merging  the  results  of  recursively  applying  quicksort  on  two 
parts  of  the  input  stream.  The  first  part  contains  values  of  the  input  stream  which  were  less  than 
the  first  value  in  the  stream.  The  second  part  contains  value  which  were  greater  than  or  equal  to 
the  first  element  in  the  input  stream.  The  expression  in  line  4  checks  to  see  if  the  current  input 
value  is  less  than  the  first  input  value.  If  so,  the  value  is  placed  into  stream  bO  (line  5).  Other¬ 
wise,  it  is  placed  into  stream  bl  (line  6).  Quicksort  is  then  recursively  called  on  these  two  streams 
(line  2).  Finally,  procedure  follow  (lines  7-10)  is  used  to  merge  the  elements  of  the  two  sorted 
streams  to  produce  a  final  result  stream  (line  2).  Procedure  follow  merges  the  two  streams  by 
producing  all  of  the  elements  of  the  first  input  stream  followed  by  all  of  the 
elements  of  the  second  input  stream. 

************************************************************************************** 


1  quicksort(a)  =  if  iseod(first  a)  then  a 

2  else  follow(quicksort(bO),quicksort(bl))  fi 

3  where 

4  p  =  first  a  <  a; 

5  bO  =  a  whenever  p; 

6  bl  =  a  whenever  not  p; 

7  follow(x,y)  =  if  xdone  then  y  upon  xdone  else  x  fi; 

8  where 

9  xdone  =  iseod  x  fby  xdone  or  iseod  x; 

10  end 

11  end 

Figure  2.6  -  example  of  a  Lucid  program  which  performs  quicksort 


token  set  for  each  input  token  set.  Thus,  the  filters  introduce  history  sensitivity  in  programs. 
The  special  filters  supported  by  the  language  include  first,  next,  fby,  whenever,  asa,  and  upon. 
These  filters  are  explained  in  Section  4.3.3.  An  example  of  the  use  of  the  special  filters  is 
presented  in  Figure  2.7.  The  evample  program  performs  mergesort  on  a  stream  of  data  values. 
Lucid  also  utilizes  the  special  is  current  declaration  which  allows  programmers  to  write  programs 
with  nested  iteration. 


When  a  user  defines  a  function  in  the  language,  the  user  is  actually  defining  a  new  filter 
which  behaves  the  same  as  the  special  filters  of  the  language.  The  function  continuously  accepts 
streams  of  input  values,  performs  computation  upon  the  input  values,  and  produces  streams  of 


*************************************************************************************** 

Procedure  msort  accepts  a  stream  of  data  values  and  performs  mergesort  by  dividing  the  input 
stream  into  two  parts,  performing  msort  on  each  of  those  parts,  and  merging  the  results  into  one 
result  stream.  If  there  is  only  one  value  in  the  input  stream  (the  second  value  in  the  stream  is  the 
special  object  eod),  then  that  value  is  returned  as  the  result  of  the  procedure  (line  1).  Otherwise, 
the  input  stream  is  divided  into  two  parts  by  using  a  boolean  value  (p)  to  place  alternative  values 
in  the  input  stream  into  two  new  streams,  bO  and  bl  (lines  5-6).  Mergesort  is  then  performed  on 
each  of  the  streams  and  the  results  are  merged.  The  value  of  p  alternates  by  using  an  fby  filter  to 
produce  a  false  value  followed  by  a  stream  of  alternating  true  and  false  values  (line  4).  In  lines  5 
and  6,  two  whenever  filters  are  used  to  place  the  values  into  the  new  streams.  If  p  is  true,  then 
the  current  input  value  is  placed  into  stream  bO;  otherwise,  it  is  placed  into  bl.  Procedure  merge 
(lines  7-15)  is  used  to  merge  the  values  of  the  two  streams  into  one  result  stream.  The  function 
uses  a  boolean  value  (takexx)  which  is  true  whenever  the  value  of  stream  xx  is  less  than  the 
current  value  of  stream  yy  or  the  current  value  of  stream  yy  is  eod.  Otherwise,  the  value  of 
takexx  is  false  (lines  11-12).  Procedure  merge  produces  the  current  value  of  xx  if  takexx  is  true; 
otherwise,  the  value  of  yy  is  produced  (line  7).  Stream  xx  is  produced  by  using  an  upon  filter  with 
x  and  takexx  as  inputs.  The  value  of  xx  is  initially  the  first  value  in  stream  x.  Then,  if  takexx  is 
true,  a  new  value  of  stream  x  is  produced;  otherwise,  the  last  value  produced  by  the  upon  filter  is 
produced  again  (line  9).  The  same  is  done  with  stream  yy,  except  the  value  of  not  takexx  is  used 
to  control  the  output  of  the  upon  filter  (line  10).  Procedure  just  is  used  to  place  an  eod  object  at 
the  end  of  its  input  stream  (lines  13-14). 

************************************************************************* ***•**••**••** 

1  msort(a)  =  if  iseod(first  next(a))  then  a 

2  else  merge(msort(bO),msort(bl))  fi 

3  where 

4  p  =  false  fby  not  p; 

5  bO  =  a  whenever  p; 

6  bl  =  a  whenever  not  p; 

7  merge(x,y)  =  if  takexx  then  xx  else  yy  fi 

8  where 

9  xx  =  just(x)  upon  takexx; 

10  yy  =  just(y)  upon  not  takexx; 

11  takexx  =  if  iseod(yy)  then  true  elseif 

12  iseod(xx)  then  false  else  xx  <  yy  fi; 

13  just(a)  =  ja  where  ja  =  a  fby  if  iseod  ja  then  eod 

14  else  next  a  fi;  end; 

15  end; 

16  end; 


Figure  2.7-  example  of  the  use  of  Lucid's  filters 


result  values.  Lucid  programs  are  also  filters  which  continuously  accept  input  values  and  produce 
output  results. 


2.4.3.  Other  Dataflow  Languages 
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Several  other  dataflow  languages  have  been  proposed  including  SISAL  and  DFL.  SISAL 
(Streams  and  Iteration  in  a  Single-Assignment  Language)  [MCGR83]  is  a  functional  dataflow 
language  which  was  developed  in  a  cooperative  effort  by  the  Lawrence  Livermore  National 
Laboratory,  Colorado  State  University,  DEC,  and  the  University  of  Manchester.  The  language’s 
main  application  is  numerical  computations.  The  language  was  designed  after  Val  and  has  many 
of  the  same  features  as  Val.  SISAL  supports  streams  and  several  operations  which  manipulate 
streams.  The  language  uses  only  one  error  value  in  every  data  type  in  contrast  to  Val’s  extensive 
error  values. 

[FAUS86]  presents  a  real-time  dataflow  language  which  is  being  developed  as  an  extension  of 
Lucid.  Lucid  is  extended  by  associating  a  stream  of  time  windows  with  each  stream  of  data 
values.  Time  windows  are  needed  and  used  because  a  real-time  language  is  concerned  with  both 
data  and  time  dependencies.  The  time  window  defines  exactly  when  a  data  value  can  be  pro¬ 
duced  by  an  operation. 

[PATN84]  discusses  a  high  level  language,  DFL  (Data  Flow  Language)  whose  syntax  closely 
resembles  Pascal.  DFL  borrows  much  of  its  languages  features  from  Val.  The  language  is  a 
block-structured,  single-assignment  language  which  uses  strong  type  checking.  DFL  has  no  provi¬ 
sions  for  records,  only  supports  two  dimensional  arrays,  and  does  not  support  user-defined  or 
stream  data  types. 

Val,  Id,  and  Lucid  were  studied  to  discover  specific  useful  features  of  each  language.  These 
features  were  incorporated  to  form  the  foundation  of  PDL.  Val  and  Id  have  many  similar 
language  features,  including  data  types  and  language  constructs.  Since  the  features  are  similar, 
they  can  be  extracted  from  only  one  of  the  languages.  Val  was  chosen.  The  language  features 
extracted  from  Val  include  its  data  types  and  the  treatment  of  those  data  types,  all  of  the 
language’s  program  constructs,  and  most  of  the  operations  of  each  data  type.  PDL  also  uses  Val's 
static  model.  The  features  of  Val  were  augmented  by  features  taken  from  Id  and  Lucid.  The 
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only  feature  incorporated  exclusively  from  Id  is  the  apply  operator.  The  features  incorporated 
from  Lucid  include  the  use  of  streams  and  operations  to  manipulate  the  streams.  These  opera¬ 
tions  include  all  of  Lucid’s  special  filters. 


CHAPTER  3 


Specification  Techniques 


Formal  specification  techniques  have  been  widely  used  to  specify  “non-graphical”  general 
purpose  programming  languages.  Specification  techniques  can  be  separated  into  two  categories, 
syntactic  and  semantic.  Syntactic  techniques  define  the  syntax  of  a  language,  but  specify  nothing 
about  the  semantics  of  the  language.  On  the  other  hand,  semantic  specifications  define  the  formal 
semantics  of  a  language,  but  are  not  concerned  with  the  syntax  of  the  language.  One  of  the  most 
widely  known  and  used  syntactic  specification  techniques  is  the  BNF  Grammar.  Many  semantic 
specification  techniques  have  been  developed  and  are  discussed  in  [PAGA81].  The  specification  of 
PDL  is  based  on  the  algebraic  technique  developed  by  Mallgren  [MALL82J  and  the  axiomatic 
technique  developed  by  Hoare  [HOAR69], 

Formal  specifications  serve  three  purposes  for  the  language  designer  and  user.  First,  the 
specification  provides  a  rigorous  unambiguous  description  of  the  language  at  some  level  of 
abstraction.  Second,  the  specification  serves  as  a  foundation  for  reasoning  about  programs  written 
in  that  language.  Last,  the  specification  serves  as  a  reference  document  for  users. 

The  specification  technique  adopted  in  this  thesis  combines  three  specification  techniques  to 
formally  describe  the  graphical  representation,  textual  syntax,  and  semantics  of  the  language. 
The  three  techniques  are  Mallgren’s  algebraic  specification  technique  used  to  describe  the  graphi¬ 
cal  representation  of  the  language,  a  BNF  grammar  used  to  describe  the  textual  syntax  of  the 
language,  and  an  axiomatic  specification  technique  used  to  describe  the  semantics  of  each 
language  feature.  In  this  chapter,  a  brief  overview  of  the  three  specification  techniques  is 
presented. 


3.1.  Mallgren’s  Algebraic  Technique 

Limited  work  has  been  done  in  the  area  of  the  specification  of  computer  graphics  program¬ 
ming  languages.  [MALL82]  notes  that  there  are  problems  with  applying  existing  specification 
techniques  to  graphical  languages.  These  problems  include: 

(1)  Graphics  applications  utilize  several  special  constructs  which  are  not  found  in  general  pur¬ 
pose  languages.  Many  of  these  special  constructs  are  inadequately  analyzed  in  the  literature 
to  provide  a  sound  basis  for  their  specification;  and 

(2)  Graphics  applications  involve  user  interaction.  The  formal  specification  of  user  interaction 
is  difficult  using  existing  techniques. 

Mallgren’s  specification  technique  utilizes  graphical  data  types,  an  algebraic  specification 
technique,  and  a  base  language  to  define  a  graphical  programming  language.  An  axiomatic 
specification  technique  is  used  to  describe  the  base  language  statements,  an  algebraic  data  type 
specification  technique  is  used  to  describe  the  graphical  data  types,  and  a  new  technique  based  on 
the  algebraic  specification  technique  is  used  to  describe  user  interaction. 

Graphical  languages  have  been  traditionally  specified  in  an  ad-hoc  manner  by  building 
structures  out  of  general-purpose  data  types  (i.e.,  integer  and  character).  Formal,  structured  tech¬ 
niques  have  not  been  developed  or  used  to  describe  the  diverse  concepts  of  graphical  languages. 
These  concepts  include  pictures,  points,  graphical  transformations,  and  user  interaction.  Mallgren 
uses  the  algebraic  specification  technique  for  abstract  data  types,  developed  by  Guttag  [GUTT78], 
to  incorporate  these  concepts  into  a  graphical  programming  language.  An  abstract  data  type  is  a 
collection  of  values  and  operations  which  manipulate  the  values.  A  specification  of  an  abstract 
data  type  is  composed  of  two  parts:  a  syntactic  specification  and  a  set  of  axioms.  The  syntactic 
specification  provides  the  syntactic  and  type  information  of  each  operation  associated  with  the 
data  type,  including  the  operation’s  name,  domain,  and  range.  The  set  of  axioms  defines  the 
meaning  of  the  operations  by  stating  relationships  between  operations.  The  axioms  are  expressed 


using  algebraic  equations. 

Graphical  data  types  encapsulate  the  concepts  of  a  graphical  programming  language  in  a 
manner  that  allows  existing  specification  techniques  to  formally  specify  the  data  types  and  the 
graphical  programming  language.  Mallgren  states  that  graphical  data  types  make  it  easy  to  write 
formal  specifications  of  graphical  languages  and  provide  tools  for  the  verification  of  programs 
written  in  these  languages.  Implementation  details  of  each  data  type  are  abstracted  away  by 
allowing  a  programmer  to  use  the  data  types  only  with  a  pre-defined  set  of  operations.  Examples 
of  an  abstract  graphical  data  type  are  given  in  Appendix  C. 

User  interaction  is  extremely  important  to  interactive  computer  graphics.  Mallgren  specifies 
user  interaction  by  extending  the  algebraic  specification  technique  to  handle  shared  data  types. 
These  data  types  are  used  to  specify  the  interaction  between  the  computing  machine  and  the  pro¬ 
grammer  in  terms  of  concurrent  processes. 

Mallgren’s  technique  uses  several  steps  to  specify  each  data  type  used  by  the  graphical 
language.  The  steps  are: 

1.  Show  the  operations  associated  with  each  data  type  in  terms  of  algebraic  equations. 

2.  Define  the  semantic  portion  of  the  specification  by  listing  the  axioms  of  each  data  type. 

3.  Divide  the  operations  into  three  categories:  generator,  inquiry,  and  basic  generators. 

a.  Generator:  Operations  which  produce  objects  of  the  type  being  defined.  These  opera¬ 
tions  are  added  for  convenience. 

b.  Inquiry:  Operations  which  produce  objects  of  other  types. 

c.  Basic  Generator:  Operations  which  are  necessary  to  generate  any  object  of  the  data 
type  being  defined. 

4.  Give  meaning  to  each  of  the  inquiry  operations  by: 


a.  Writing  axioms  for  reducing  each  generator  to  an  expression  involving  only  basic  gen¬ 
erators;  and 

b.  Provide  axioms  that  give  the  result  of  applying  each  inquiry  operation  to  each  of  the 
basic  generators. 

5.  Define  synonyms  for  some  of  the  operations  providing  an  infix  notation  for  binary  opera¬ 
tions  which  are  frequently  used. 

Mallgren  has  defined  several  data  types  which  are  used  as  a  nucleus  of  a  simple  program¬ 
ming  language.  Many  of  these  data  types  will  be  used  to  help  define  the  graphical  dataflow  pro¬ 
gramming  language  developed  in  this  thesis.  These  data  types  include  region,  point,  name,  user 
interaction,  and  continuous  picture.  Each  of  these  data  types  are  presented  in  Appendix  C. 

3.2.  Hoare’s  Axiomatic  Technique 

The  axiomatic  specification  technique  (Hoare  Calculus)  was  developed  by  C.  A.  R.  Hoare  to 
prove  the  partial  correctness  of  programs  [HOAR69],  The  technique  is  based  on  the  specification 
of  axioms  and  rules  of  inference  used  to  prove  programs  correct.  The  axioms  are  used  to  prove 
simple  program  statements,  while  the  rules  of  inference  are  used  to  prove  the  structured  state¬ 
ments  of  programs.  By  using  rules  of  inference,  properties  of  the  structured  statements  are 
deduced  from  the  properties  of  its  constituents. 

Apt  [APT81]  presents  an  excellent  overview  of  relevant  issues  concerning  the  axiomatic 
specification  technique  including  the  specification  of  procedures  with  parameters,  recursion,  and 
variable  declaration.  Apt  also  discusses  the  soundness,  completeness,  incompleteness  of  axiomatic 
specifications,  and  gives  a  comprehensive  reference  list  of  other  work  concerning  axiomatic 
specifications.  Hoare  [HOAR73]  presents  a  complete  axiomatization  of  the  programming  language 
Pascal,  including  the  first  proof  rule  for  the  assignment  of  array  elements.  The  programming 
language  Euclid  [LOND78]  was  designed  with  the  idea  of  axiomatization  in  mind.  In  designing 
Euclid,  it  has  been  seen  that  axiomatizing  a  language  during  its  development  is  easier  than  writ¬ 
ing  axioms  for  the  language  after  it  has  been  developed.  We  chose  to  write  the  specification  dur¬ 
ing  the  design  phase  and  found  that  this  exercise  had  a  positive  influence  on  PDL’s  d  ■sign. 
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The  axiomatic  technique  associates  assertions  about  the  values  of  variables  at  the  beginning 
and  end  of  the  execution  of  a  program  or  program  statement.  Pre-conditions  are  the  assertions 
about  the  variables  at  the  beginning  of  execution  while  post-conditions  are  the  assert'-  us  at  the 
end  of  execution.  The  assertions  are  expressed  in  a  strict  first-order  predicate  logic  notation. 
Assertions  of  the  form  P{S}Q  are  used  to  state  the  relationship  between  the  pre-condition  (P), 
post-condition  (Q),  and  the  program  or  program  statement  (S). 

The  axioms  and  rules  of  inference  are  used  to  describe  the  semantics  of  a  programming 
language  up  to  termination  (the  axioms  and  rules  do  not  ensure  that  the  program  will  terminate). 
The  assertion  P{S}Q  states  that  “if  P  is  true  before  the  initiation  of  program  S,  then  Q  will  be 
true  on  its  completion”  [HOAR69],  Rules  of  inference  permit  the  deduction  of  new  assertions 
from  one  or  more  assertions  previously  proven  correct.  The  rules  of  inference  have  the  two  forms 
shown  in  Figure  3.1.  The  first  rule  stat  -s  that  if  Hr  ....  Hn  are  true  assertions,  then  H  is  a  true 
assertion.  The  second  rule  states  that  if  Hn+1  can  be  proven  correct  from  assertions  H];  ...,  Hn, 
then  H  is  a  true  assertion. 

Hoare  initially  developed  one  axiom  for  assignment  and  three  rules  of  inference  for  a  con¬ 
ventional  imperative  language.  The  notation  used  for  the  axiom  and  rules  is  shown  in  Figure  3.2. 
The  axiom  of  assignment  states  that  if  P(x)  is  true  after  the  assignment,  then  P(J)  must  have 
been  true  before  the  assignment.  X  is  an  identifier  and  /  is  an  expression  of  the  programming 
language  which  may  contain  x.  P[f/x]  is  denoted  by  substituting  /  for  all  free  occurrences  of  x. 

H„  ,Hn  H„  •  ■  ,Hn  |-Hn+1 

II  H 

Figure  S.l  -  the  forms  of  Hoare ’s  rules  of  inference 
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The  axiom  is  actually  a  schema  which  defines  an  infinite  number  of  axioms  which  share  a  common 
form.  The  rules  of  consequence  are  straightforward  and  need  no  explanation.  The  rule  of  compo¬ 
sition  states  that  if  the  result  of  the  first  program  statement  is  the  same  as  the  pre-condition  of 
the  second  statement,  then  the  composition  of  the  two  will  produce  the  result  of  the  second  state¬ 
ment.  The  rule  of  iteration  states  that  if  an  assertion  is  true  on  the  initiation  of  a  loop,  and  it  is 
true  after  any  number  of  iterations  of  the  loop;  and  that  on  the  final  iteration  of  the  loop,  the 
boolean  test  (B)  will  be  false. 

Assignment  Axiom:  P0{x:=f}P 

If  I— P{S}Q  and  |— Q  D  R  then  |— P{S}R 

Rules  of  Consequence: 

If  I— P{S}Q  and  I— R  z>  P  then  |— R{S}Q 
Rule  of  Composition:  If  \— P  {S,}Q  and  |— Q  {S2}R  then  |—  P  {Si;S2}R 
Rule  of  Iteration:  If  | — PAB{S}P  then  | — P{while  B  do  S}->BAP 

Figure  3.2  -  Hoare’s  Axiom  and  Rules  of  Inference 


3.3.  BNF  Grammar 

The  BNF  (Backus-Naur  Form)  grammar  was  originally  developed  to  syntactically  describe 
ALGOL  and  has  been  widely  used  in  language  definition.  The  grammar  consists  of  several  pro¬ 
ductions  or  BNF  grammar  rules  which  specify  allowable  sequences  of  character  strings  in  the 
language  being  described.  The  grammar  defines  a  programming  language’s  legal  syntax  but 
describes  nothing  about  the  semantics  of  the  language. 

The  grammar  rules  have  the  form: 

< syntactic  category >  ::=  <definition> 
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where  the  syntactic  category  is  the  name  of  the  language  construct  or  feature  defined  by  the 
grammar  rule.  The  means  that  the  syntactic  category  is  defined  by  the  expression  on  the 

right  side.  The  expression  can  be  as  simple  as  a  list  of  objects,  (e.g.,  a  list  of  letters)  or  can  con¬ 
sist  of  other  syntactic  categories.  Recursive  definitions  are  also  allowed.  Once  a  syntactic 
category  has  been  defined,  it  can  be  used  in  other  syntactic  categories  to  build  more  complex 
language  constructs.  A  complete  BNF  grammar  of  a  programming  language  is  defined  by  a 
hierarchy  of  grammar  rules  (syntactic  categories).  The  top-level  syntactic  category  of  the  hierar¬ 
chy  is  the  program. 

Each  of  the  specification  techniques  discussed  in  this  chapter  were  combined  into  a  multi¬ 
dimensional  specification  technique  introduced  in  Chapter  5.  The  specification  will  describe  the 
semantics  (behavior),  syntax,  and  graphical  representation  of  each  language  construct  of  PDL. 


CHAPTER  4 


PDL:  the  Prototype  Dataflow  Language 


In  this  chapter,  an  overview  of  PDL,  with  its  language  features,  and  an  explanation  of  the 
design  goals  and  motivations  of  the  language,  is  presented.  In  Section  4.1,  the  design  goals  of  PDL 
are  presented.  In  the  design  of  PDL,  Val  is  used  as  a  core  language  extended  with  other  useful 
features  such  as  Id’s  apply  operator  and  Lucid’s  filters  and  streams.  In  Section  4.2,  the  features  of 
Val  incorporated  into  PDL’s  design  are  presented.  Much  of  the  textual  syntax  of  PDL  follows 
Val.  A  detailed  description  of  PDL’s  syntax  is  given  in  Appendix  B.  In  Section  4.3,  the  features 
of  Lucid  incorporated  into  PDL’s  design,  including  the  concepts  of  streams  and  filters,  are 
presented.  In  Section  4.4,  the  apply  operator,  a  feature  incorporated  from  Id  is  presented. 

As  each  syntactic  language  construct  is  presented,  the  abstraction  icons8  used  to  represent 
the  construct  and  the  lower-level  dataflow  diagram  of  the  construct  are  presented.  Specific  graphi¬ 
cal  icons  were  taken  from  the  graphical  base  languages  introduced  in  Section  2.2  to  represent  the 
base  language  representations  of  the  constructs.  In  Section  4.5,  the  motivations  for  the  features 
of  PDL  are  presented.  Icon  design  was  not  one  of  the  objectives  of  this  work.  Sample  icons  are 
proposed  and  presented  to  give  the  reader  an  appreciation  of  the  potential  of  the  prototype 
language.  Programmers  may  define  and  use  their  own  abstraction  icons. 

4.1.  Design  Goals 

Three  design  goals  have  been  followed  in  the  development  of  PDL.  The  main  design  goal 
for  PDL  is  that  the  language  support  the  simultaneous  existence  of  graphical  and  textual 

9  In  this  chapter,  an  icon  refers  to  a  node  in  the  program  graph.  The  icon  (node)  represents  an  operation  in  the 
program  graph.  Thus,  an  icon  is  allowed  to  perform  some  action. 


representations  for  each  language  construct.  Most  dataflow  languages  express  programs  in  a  tex¬ 
tual  notation  which  are  translated  into  a  graphical  base  language  (a  directed  program  graph).  A 
user-friendly  programming  environment  would  support  the  coexistence  of  graphical  and  textual 
representations.  For  this  reason,  both  representations  are  incorporated  into  the  design  of  PDL. 

The  second  design  goal  is  for  PDL  to  be  extensible.  Because  the  language  was  designed  to 
be  a  prototype  language,  it  is  anticipated  that  the  language  will  evolve.  As  the  language  is  used, 
programming  constructs  may  be  added  or  deleted  to  improve  the  usefulness  of  the  language.  New 
features  can  be  added  to  the  language  by  defining  the  textual  and  graphical  representations  of  the 
construct  along  with  its  semantics. 

The  final  design  goal  for  the  language  is  to  make  abstraction  a  major  part  of  the  language. 
Each  function  of  the  language  is  thought  of  as  an  abstraction  of  its  sub-parts.  Each  sub-graph 
(function)  is  represented  as  a  single  node  in  a  graph  (program).  A  programmer  needs  to  view  the 
lower-level  diagram  only  when  the  diagram  is  created  or  manipulated.  The  programmer  needs  to 
know  only  what  a  function  does,  not  how  it  performs  its  operations.  Abstraction  of  all  language 
constructs  eases  the  programmer’s  task  of  program  construction  by  allowing  an  abstraction  icon 
to  represent  a  complex  function  graph,  and  allows  for  easy  use  of  the  language  since  the  program¬ 
mer  need  not  be  concerned  about  the  complex  details  of  a  program  graph.  Abstraction  also  allows 
for  easy  program  readability  since  the  complexity  of  a  program  graph  can  be  reduced  through  the 
use  of  abstraction  icons.  Abstraction  icons  are  utilized  by  PDL  to  represent  each  language  con¬ 
struct,  where  appropriate,  and  user-defined  operation.  An  example  of  the  abstraction  icon  used  to 
represent  the  forall  construct  is  shown  in  Figure  4.1.  The  lower-level  dataflow  diagram  of  the  con¬ 
struct  is  shown  in  Figure  4.2.  Each  fat  arc  in  the  diagram  represents  a  collection  of  arcs  from  one 
node  to  another.  The  functions  of  each  node  in  the  diagram  will  be  explained  in  Section  4.2.4. 

4.2.  Features  Taken  From  Val 

The  language  features  of  Val  which  were  incorporated  into  PDL’s  design  include  its  data 
types  and  the  treatment  of  those  data  types;  all  of  the  language’s  program  constructs,  including 
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4.2.1.  Data  Types 

The  primitive  types  supported  in  PDL  are  integer,  real,  boolean,  and  character.  The  com¬ 
pound  data  types  supported  include:  array,  record,  union,  and  function.  The  union  data  type  of 
PDL  is  Val’s  oneof  data  type.  PDL  also  supports  programmer-defined  data  types  which  are  con¬ 
structed  using  the  primitive  and  compound  types.  Array  types  have  no  bounds  associated  with 
them.  The  type  of  the  array  is  the  type  of  the  constituent  elements  which  must  all  have  the  same 
type.  Strings  are  represented  as  an  array  of  characters.  Union  types  allow  discriminated  union 
data  types.  A  union  type  is  composed  of  several  tags  and  the  types  associated  with  each  of  the 
tags.  When  a  value  of  type  union  is  created,  a  programmer  supplies  the  tagname  and  a  consti¬ 
tuent  value  whose  type  is  the  type  associated  with  the  tagname.  Identifiers  of  type  union  will  be 
bound  to  one  of  the  constituent  values  and  will  have  that  value’s  type.  The  case  construct  is 
used  to  access  the  constituent  values  of  a  union  type.  An  example  of  this  type  will  be  given  when 
the  case  construct  is  discussed.  Values  of  type  function  are  procedure  definitions  which  are  util¬ 
ized  with  the  apply  operator  which  is  described  in  Section  4.4.  Associated  with  each  type  is  a 
value  domain,  which  consists  of  the  proper  elements  of  the  type,  one  error  element,  and  several 
operations  to  manipulate  values  of  the  type. 

4.2.2.  Values 

PDL  is  value-oriented;  all  identifiers  (value  names),  including  compound  objects,  are  as 
treated  values.  The  language  also  uses  the  single  assignment  convention,  but  in  an  different 
manner.  Identifiers  denote  not  just  a  single  value,  but  an  arbitrarily  long  sequence  of  values.  The 
use  of  sequences  is  fully  explained  in  Section  4.4.1. 

Identifiers  can  be  bound  to  values  of  any  type.  The  type  of  the  identifier  is  specified  when 
the  identifier  is  first  used  in  the  program  or  in  the  type  definitions  section  of  the  program.  When 
a  value  is  bound  to  the  identifier,  the  type  of  the  value  must  be  equivalent  to  the  identifier’s  type. 
If  the  two  types  are  not  equivalent,  no  automatic  type  conversion  will  occur  and  an  error  value  of 
the  appropriate  type  is  bound  to  the  identifier.  Once  a  binding  is  made,  that  binding  remains  in 
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force  for  the  entire  scope  of  the  identifier.  The  scope  of  an  identifier  is  the  body  of  the  function 
or  program  construct  in  which  a  reference  to  the  value  name  denotes  its  value. 

Like  Val,  PDL  incorporates  extensive  type-checking.  All  operations  accept  a  specific  type  of 
input.  If  a  token  arrives  that  does  not  have  the  correct  type,  an  error  value  of  the  appropriate 
type  is  produced.  For  example,  if  the  add  operation  receives  a  data  value  whose  type  is  not 
integer  or  real,  then  an  error  value  of  the  appropriate  type  is  produced.  Also,  all  formal  and 
actual  parameters  are  checked  for  type  equivalence.  If  the  types  of  the  parameters  are  not 
equivalent,  an  error  value  is  produced  by  the  function. 

Graphically,  the  arcs  of  a  program  graph  represent  identifiers.  The  scope  of  an  identifier  is 
the  node  from  which  the  arc  emanates  and  all  nodes  to  which  it  enters.  Each  arc  is  labeled  with 
the  type  of  the  token  that  the  arc  carries.  Unique  labels  for  each  type  are  given  in  Table  4.1. 
When  a  programmer  defines  a  new  data  type,  a  unique  label  is  associated  with  arcs  which  carry 
tokens  of  that  type. 

4.2.3.  Expressions  and  Operators 

All  instructions,  language  constructs,  and  function  definitions  in  PDL  are  expressions.  The 
primitive  expressions  are  the  arithmetic  and  boolean  expressions  which  consist  of  one  or  more 

Data  type  Label 

integer  IN 

real  RE 

character  CH 

boolean  BL 

array  AR 

record  RC 

union  UN 

function  FN 

Table  \.l  -  arc  labels  for  data  types 
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operations  acting  upon  several  operands.  These  expressions  are  expressed  in  prefix  notation.7  The 
operations  actually  perform  pointwise  computation  upon  streams  of  operand  values.  The  use  of 
pointwise  operations  is  explained  in  Section  4.3.1.  Operations  may  fire  or  execute  only  when  each 
of  its  input  arcs  carry  a  token  and  its  output  arcs  are  empty.  The  primitive  operations  can  be 
utilized  in  user-defined  functions  and  program  constructs.  The  primitive  operations  of  each  data 
type  are  presented  in  Appendix  E. 

Each  primitive  operation  is  represented  graphically  by  one  of  the  function  icons  shown  in 
Figure  4.3.  The  icon  is  labeled  with  the  name  of  the  operation  or  a  symbol  denoting  the  opera¬ 
tion.  Each  icon  has  either  one,  two,  or  three  input  arcs  and  an  output  arc.  If  the  output  of  an 
operation,  represented  by  a  function  icon,  is  needed  by  more  than  one  instruction,  the  output 
token  is  transmitted  through  a  fork  which  produces  the  appropriate  number  of  replicated  tokens. 

Operands  are  either  constants  or  identifiers  which  are  bound  to  some  value.  A  PDL  constant 
can  be:  true,  false,  nil,  integer  numbers,  real  numbers,  character  constants,  character  string  con¬ 
stants,  and  error[type-spec]  which  specifies  an  error  value  of  some  type. 


Figure  4-3  -  graphical  representation  of  primitive  functions 


7  Val  uses  an  infix  notation  for  its  operations.  A  prefix  notation  was  used  for  PDL  to  exploit  the  easy  correlation 
between  a  displayed  graph  and  its  corresponding  textual  representation.  It  is  straightforward  to  translate  the  prefix  nota¬ 


tion  into  a  infix  notation. 


Operands  are  represented  graphically  by  the  arcs  of  the  data  flow  program  graph.  Each  arc 
is  labeled  with  the  token  type  and  optionally  with  the  name  of  the  identifier  the  arc  denotes. 
Constants  are  represented  by  the  icon  shown  in  Figure  4.4.  The  value  of  the  constant  is  the  label 
of  the  icon.  The  icon  has  one  input  arc  which  is  used  as  a  trigger.  When  a  token  of  any  type  is 
present  on  the  input  arc,  the  icon  will  produce  the  constant.  A  trigger  was  used  to  ease  the  reali¬ 
zation  of  program  graphs. 


Figure  4-4  -  graphical  representation  of  constants 

4.2.4.  Language  Constructs 

The  program  constructs  of  PDL  include  the  begin,  if-lhen-else,  case  (Val  uses  the  tagcase 
construct),  for-iter,  and  forall  constructs.  Each  of  the  constructs  are  expressions,  called  multi¬ 
expressions,  which  produce  a  tuple  of  result  values.  The  syntax  of  each  language  construct  is 
given  in  Appendix  B. 

Each  construct  is  represented  by  an  abstraction  icon,  where  appropriate.  Many  of  these 
icons  are  incorporated  from  the  symbols  of  Nassi-Shneiderman  diagrams  [NASS73],  The  icons  are 
an  abstract  representation  of  the  lower-level  dataflow  diagrams  of  the  constructs  (if  a  diagram  is 
supported).  The  lower-level  diagrams  are  represented  using  data-dependent  and  user-defined 
function  icons  incorporated  from  the  graphical  base  languages  discussed  in  Section  2.3.  The  pro¬ 
gram  constructs,  the  abstraction  icon  used  to  represent  the  construct,  and  icons  used  to  define  the 


lower  level  diagrams  of  each  construct  are  now  discussed. 

4. 2.4.1.  If-Then-Else  Construct 

The  if-thcn-clsc  construct  permits  the  selection  of  two  alternative  expressions  which  return 
result  values  depending  upon  a  boolean  test  expression.  This  construct  is  similar  to  those  used  in 
conventional  languages  except  that  all  input  values  used  within  the  two  alternative  expressions 
must  be  present  for  the  construct  to  fire.  Each  alternative  expression  receives  every  input  value. 
The  construct  produces  an  error  value  if  the  test  expression  or  an  alternative  expression  returns 
an  error  value. 

The  abstraction  icon  used  to  represent  the  if-then-else  construct  is  shown  in  Figure  4.5. 
Five  icons  are  used  to  represent  the  lower-level  dataflow  diagram  of  the  construct;  one  icon  for 
the  test  expression,  one  for  each  of  the  two  alternative  expressions,  and  two  data-dependent 
nodes.  The  two  data-dependent  nodes,  merge  and  switch,  are  used  to  pass  input  values  to  the 
selected  alternative  and  the  correct  result  values  out  of  the  construct.  Both  icons  are  controlled 
by  the  same  control  token  produced  by  the  boolean  test  icon.  Both  of  these  icons  were  incor¬ 
porated  from  Kosinski’s  graphical  base  language  mentioned  in  Section  2.3.2.  The  lower  level 
diagram  is  shown  in  Figure  4.6. 

4. 2.4. 2.  Begin  Construct 

The  begin  construct  is  used  to  compute  several  sub-expressions.  The  result  from  the  sub¬ 
expressions  are  used  to  compute  a  final  result  which  is  returned  using  the  return  expression.  The 
return  expression  is  Val’s  result  expression.  The  construct  introduces  new  identifiers  and  bind 
values  to  the  identifiers  using  the  sub-expressions.  These  identifiers  can  be  used  in  the  return 
expression. 

The  begin  construct  is  graphically  represented  by  the  abstraction  icon  shown  in  Figure  4.7. 
The  icon  is  identical  to  Nassi-Shneiderman’s  Begin-End  symbol.  The  lower-level  dataflow 
diagram  of  the  construct  is  defined  by  the  sub-graph  composed  of  the  construct’s  constituent 
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Figure  ^.7-  graphical  representation  of  the  Begin  construct 


4. 2.4. 3.  Case  Construct 

The  case  construct  accesses  values  bound  to  identifiers  of  type  union.  An  example  of  the 
construct  is  shown  in  Figure  4.8.  The  result  of  a  case  construct  is  the  value  of  the  expression  or 
arm  whose  tag  name  matches  the  value  of  the  test  expression  of  the  construct.  If  no  match  occurs, 
then  the  result  is  the  construct’s  default  expression.  The  default  expression  of  PDL  is  Val’s  other¬ 
wise  expression.  The  expression  following  the  wo:d  case  (i.e.,  the  test  expression)  must  be  of  type 
union  and  the  tag  names  in  the  expressions  (arms)  of  the  construct  must  be  the  tags  of  that  union 

Let  X  be  of  type:  union[A:int;  B:array[int];  C:real] 

If  X  has  tag  A  and  constituent  value  3, 

case  P:=X 
tag  A:  P  +  4 

tag  B:  P [6] 

tag  C:  P  +  2.35 

end 

the  value  produced  by  the  construct  will  be  7.  The  union  type  has  three  tags,  one  of  type  integer, 
one  of  type  array,  and  one  of  type  real. 

Figure  4-8  -  example  of  the  case  construct 


type.  If  the  tag  names  of  the  construct  comprise  every  tag  in  the  union  type,  then  the  default 
expression  is  not  needed.  The  identifier  which  appears  after  the  word  case  is  introduced  into 
each  expression  of  the  construct  excluding  the  default  arm.  The  type  of  the  identifier  is  the  type 
indicated  by  the  tag  of  a  certain  expression.  When  an  expression  is  executed  (i.e.,  the  tag  of  the 
test  expression  matches  the  tagname  of  the  executing  expression),  the  value  name  is  bound  to  the 
value  from  the  test  expression. 

No  abstraction  icon  is  utilized  for  the  case  construct.  The  ease  construct  is  graphically 
represented  by  the  lower-level  dataflow  diagram  shown  in  Figure  4.9.  The  route  tokens  icon 
passes  any  input  values  and  control  to  the  correct  expression  depending  upon  the  value  of  the 
input  tag.  Once  the  input  values  have  passed  to  the  correct  expression,  that  expression  executes 
and  passes  its  result  values  to  the  funnel  tokens  icon.  The  funnel  tokens  icon  collects  the  input 


Figure  4  9-  graphical  representation  of  the  Case  construct 


tokens  from  the  group  of  arcs  specified  by  the  token  on  the  first  input  arc.  The  icon  places  the 
tokens  on  its  output  arcs  in  the  order  that  the  tokens  were  collected.  The  route  tokens  and  funnel 
tokens  are  abstraction  icons. 

4. 2.4. 4.  For- Iter  Construct 

The  for-iter  construct  is  used  for  iteration  where  the  result  of  one  iteration  of  the  loop  is 
dependent  upon  the  results  of  previous  iterations.  By  using  the  iter  expression  within  the  con¬ 
struct,  value  names  are  rebound  to  new  values  just  prior  to  the  next  iteration  of  the  loop.  The 
construct  consists  of  four  parts:  the  initialization  of  variables,  a  test  for  loop  termination,  the 
redefinition  of  the  loop  identifiers,  and  the  production  of  result  values 

The  for-iter  construct  is  graphically  represented  by  the  abstraction  icon-  >h«mn  in  Figure 
4.10.  A  lower-level  diagram  is  not  supported.  One  icon,  the  loop  ••ontml  i  <>n  i*  used  to  accept 
the  initial  values  of  the  loop  identifiers, test  for  loop  terminate  ■,  and  j -•du result  value- 
There  is  one  input  arc  for  each  initial  value  and  one  output  arc  *m:.  .natine  fr  >tn  the  i.  on  for  each 
value  produced  by  the  loop.  On  successive  iterations,  the  control  i .-on  he  k-  the  termination  test 
for  a  true  result.  If  the  result  is  true,  the  icon  outputs  the  final  values  of  the  loop  variables  Oth¬ 
erwise,  the  variables  are  re-iterated  (passed  to  the  loop  body  icon)  The  second  icon,  which  is  an 
abstract  representation  of  the  body  of  the  loop,  is  used  to  update  the  loop  identifiers  after  each 
iteration  of  the  loop.  Any  number  of  input  and  output  arcs  are  allowed  to  enter  and  leave  the 
body  of  the  loop. 

4. 2. 4. 5.  Forall  Construct 

The  forall  construct  is  used  to  explicitly  specify  concurrency  in  PDL.  Using  the  forall  con¬ 
struct,  all  cycles  of  a  loop  are  performed  simultaneously.  The  construct  generates  a  set  of  values, 
and  either  produces  the  set  as  an  array  or  produces  the  result  of  performing  some  operation  on 
the  set.  The  forall  construct  consists  of  three  parts:  the  range  specification  which  defines  the 
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Figure  4-10-  graphical  representation  of  the  for-iter  construct 


parallelism  within  the  construct,  the  body  which  contains  the  expressions  to  be  evaluated,  and  the 
result  accumulator  which  collects  the  results  of  the  expressions  and  produces  an  array  or  a  single 
result.  The  range  specifies  the  number  of  separate  and  independent  instantiations  of  the  body  of 
the  forall.  Each  instantiation  of  the  body  proceeds  asynchronously.  Two  types  of  result  accumu¬ 
lators  are  used:  the  construct  accumulator  and  the  cval  accumulator.  The  construct  accumulator 
produces  a  one  dimensional  array  where  each  element  in  the  array  is  one  of  the  values  produced 
by  an  instantiation  of  the  forall  body.  The  cval  accumulator  produces  a  single  result  which  is 
computed  by  performing  an  associative  and  commutative  operation  (i.e. ,  addition  or  multiplica¬ 
tion)  upon  the  result  values  of  the  instantiations.  Only  one  result  accumulator  can  be  used  in  a 
forall  loop. 

The  forall  construct  is  graphically  represented  by  the  abstraction  icon  shown  in  Figure  4.1. 
The  icons  used  to  represent  the  lower  level  diagram  of  the  construct  are  shown  in  Figure  4.2.  The 
forall  body  is  instantiated  once  for  each  element  in  the  range  of  the  construct.  The  input  arcs  of 
the  distribute  icon  carry  the  lower  and  upper  bounds  of  the  range  and  any  input  values  used 
within  the  forall  body  (represented  by  the  fat  arc).  The  distribute  icon  passes  one  element  of  the 
range  to  each  instance  of  the  body  of  the  construct.  One  of  two  accumulator  icons  may  be  used; 
the  construct  accumulator  or  the  eval  accumulator.  The  op_name  label  of  the  cval  icon  is  the 
operation  performed  on  the  results. 


4.2.5.  User-defined  Functions 


PDL  incorporates  Val’s  function  definitions  and  calling.  Functions  are  allowed  to  have  as 
many  parameters  as  needed.  The  types  of  all  parameters  and  the  returned  values  must  be 
specified  in  the  function  header.  Formal  and  actual  parameters  must  have  equivalent  types  or  an 
error  is  produced  by  the  function.  All  parameters  are  values  and  cannot  be  rebound  in  the  func¬ 
tion  body.  The  function  body  contains  several  expressions  which  can  produce  multiple  results 
including  simple  expressions,  language  constructs,  and  other  function  calls. 

User-defined  functions  are  graphically  represented  by  the  abstraction  icon  shown  in  Figure 
4.11.  The  icon  is  an  abstract  representation  of  the  lower-level  diagram  or  sub-graph  of  the  com¬ 
ponent  expressions  of  the  function.  The  number  of  input,  output  arcs  is  equivalent  to  the  number 
of  input,  output  parameters  defined  in  a  function  header.  The  label  of  the  icon  is  the  name  of  the 
function  it  represents.  Programmers  can  define  unique  icons  to  denote  user-defined  functions. 

4.3.  Features  Taken  From  Lucid 

This  section  presents  the  language  features  of  Lucid  incorporated  into  PDL.  These  features 
include  the  use  of  sequences  instead  of  single  values  for  all  identifiers  and  Lucid’s  special  filters. 
Since  the  identifiers  denote  sequences  of  data  tokens  (values),  the  operations  of  the  language  per- 

1  1 

user-defined 
function  box 

L  I  I 

Figure  4-11-  graphical  representation  of  a  user- defined  function 


form  pointwise  computation  on  streams.  These  operations  are  called  niters. 
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4.3.1.  Infinite  Sequences 

The  identifiers  of  PDL  denote  an  arbitrarily  long  sequence  (or  stream)  of  values,  not  just  a 
single  value.  Each  sequence  has  an  associated  data  type;  all  elements  of  the  sequence  are  of  that 
type.  Associated  with  each  sequence  are  the  special  BOS  and  EOS  control  tokens.  The  BOS  and 
EOS  tokens  denote  the  beginning  and  end  of  a  sequence,  respectively.  A  Stream  can  contain  a 
single  value  by  having  the  single  value  enclosed  by  BOS  and  EOS  tokens.  Sequences  are  graphi¬ 
cally  represented  by  the  input  and  output  arcs  of  a  program  graph. 

4.3.2.  Operators  are  Filters 

All  operations  in  the  language  accept  sequences  of  data  and  produce  a  sequence  of  result 
values.  The  operations  act  as  pointwise  filters,  continuously  producing  a  set  of  output  values  for 
each  set  of  input  values.  The  semantics  of  most  operations  direct  an  operation  to  scan  for  the 
BOS  token.  When  the  BOS  token  is  present  on  each  of  the  input  arcs,  a  BOS  token  is  placed  on 
each  of  the  output  arcs.  As  each  set  of  input  values  is  absorbed,  the  operation  performs  its  com¬ 
putation  upon  the  values,  producing  a  set  of  output  values  which  are  placed  on  the  output  arcs. 
Each  input  arc  must  carry  a  token  and  the  output  arcs  must  be  empty  before  a  filter  can  fire. 
After  the  filter  has  fired,  the  input  arcs  are  empty  and  the  output  arcs  will  carry  result  tokens. 
When  an  EOS  token  is  present  on  each  of  the  input  arcs,  an  EOS  token  is  placed  on  the  output 
arcs.  The  operation  is  now  considered  to  be  finished  firing.  The  firing  of  the  merge  is  different. 
When  a  BOS,  EOS  token  is  present  on  the  control  arc,  the  node  places  the  BOS,  EOS  on  the  out¬ 
put  arc.  All  filters  operate  in  parallel  and  asynchronously. 

4.3.3.  Special  Filters 

PDL  incorporates  Lucid's  special  filters  to  isolate  certain  values  of  a  sequence  or  to  create 
new  sequences.  Two  sub-classes  of  special  filters  are  used.  One  sub-class  extracts  certain  ele¬ 
ments  from  a  stream  and  produces  new  streams  from  other  streams.  This  sub-class  accepts  input 


stream(s)  of  any,  but  equivalent  type.  Included  in  this  sub-class  are  the  first,  rest,  and  concaten¬ 
ate  filters8.  The  second  sub-class  prc  luces  a  resultant  data  stream  depending  upon  the  values  of  a 
corresponding  control  stream.  This  sub-class  accepts  two  input  streams;  one  of  which  consists  of 
data  tokens  of  any  type,  and  the  other  of  which  consists  of  boolean  control  tokens.  Included  in 
this  sub-class  are  the  whenever,  advance_upon,  and  as_soon_as  filters.  All  special  filters  can  per¬ 
form  either  pointwise  or  non-pointwise  computation.  Non-pointwise  filters  are  an  extension  of 
pointwise  filters  because  these  filters  can  have  some  internal  memory  associated  with  them.  Non- 
pointwise  filters  can  maintain  their  identity  between  each  token  of  the  input  stream  and/or  need 
not  produce  an  output  token  set  for  each  input  token  set.  Thus,  the  special  filters  are  history  sen¬ 
sitive  functions.  A  brief  explanation  of  each  filter  follows.  The  syntax  of  the  filters  is  given  in 
Appendix  B. 

first:  This  filter  produces  a  stream  of  tokens,  each  having  the  value  of  the  first  token  in 

the  input  stream. 

rest:  The  output  of  this  filter  depends  upon  the  current  step  in  the  execution  of  a  pro¬ 

gram.  At  each  step  of  the  execution,  the  output  token  produced  is  the  next  token 
to  arrive  on  the  input  arc  (i.e.,  the  next  token  in  the  stream).  The  filter  discards 
the  first  value  of  the  input  stream.  The  stream  produced  is  the  input  stream  less 
the  first  token. 

concatenate:  This  filter  produces  a  resultant  stream  which  is  formed  by  concatenating  the 

second  input  stream  to  the  first  input  stream. 

8  Some  of  the  names  of  the  filters  incorporated  from  Lucid  have  been  changed  to  clarify  their  usage. 


whenever: 
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For  each  input  token  set,  if  the  value  of  the  boolean  control  token  is  true,  then 


the  data  token  is  placed  on  the  output  arc.  Otherwise,  the  filter  discards  the  data 
token.  The  filter  produces  a  stream  of  all  values  of  the  data  stream  for  which  the 
corresponding  control  stream  values  were  true. 


as_soon_as:  This  filter  repeatedly  inputs  token  sets  until  the  control  token  value  is  true.  If 

the  control  token  value  is  never  true,  the  filter  produces  nothing.  The  filter  pro¬ 
duces  a  stream  of  values,  each  token  in  the  stream  having  the  value  equivalent  to 
the  corresponding  data  value  for  the  first  true  control  value. 


advance_upon:  This  filter  accepts  and  places  the  first  data  value  on  its  output  arc.  Then,  as  suc¬ 
cessive  token  sets  are  input,  if  the  value  of  the  control  stream  is  true,  a  new  data 
value  is  input  and  placed  on  the  output  arc.  Otherwise,  the  old  data  value  is 
repeated  and  placed  on  the  output  arc  again.  Thus,  the  data  stream  is  stretched 
by  repeating  some  of  its  values. 

The  graphical  icon  used  to  represent  the  first  and  rest  filters  is  shown  in  Figure  4.12a.  The 
icon  has  one  input  arc  and  one  output  arc.  The  graphical  icon  used  to  represent  the  other  filters 
is  shown  in  Figure  4.12b.  This  icon  has  two  input  arcs  and  a  single  output  arc. 
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|  Figure  -  icon  used  for  the  first  and  rest  filters 
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Figure  4.12b  -  icon  used  for  the  concatenate,  whenever,  as_soon_as,  and  advance_upon  filters 


4.3.4.  Is  Current  Declaration 

The  use  of  Lucid’s  special  filters  and  streams  necessitates  the  use  of  Lucid’s  it  current 
declaration.  The  declaration  allows  programmers  to  write  programs  with  nested  iteration.  When 
a  programmer  uses  nested  iteration  in  PDL,  the  values  of  outer  loop  identifiers  must  remain  con¬ 
stant  while  the  values  of  inner  loop  identifiers  take  on  each  value  in  the  stream.  The  declaration 
is  used  to  freeze  a  certain  value  of  an  outer  loop  identifier  which  can  then  be  utilized  in  the  inner 
loop.  Figure  4.13  presents  an  example  of  the  use  of  the  ia  current  declaration.  The  effect  of  the 
example  is  to  set  up  an  outer  loop  in  which  x  and  n  are  only  updated  between  executions  of  the 
inner  loop  (lines  3-4).  The  values  of  X  and  N  are  the  frozen  values  of  the  tokens  from  streams  x 
and  n.  For  example,  if  stream  x  contains  the  elements  1,  2,  and  3,  and  stream  n  contains  the  ele- 


1  t  =  asa(p,=(index,N)) 

2  where 

3  X  is  current  x; 

4  N  is  current  n; 

5  p  =  concatenate^, *(p,X)); 

6  end 


Figure  4.  IS  -  example  of  the  is  current  declaration 
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ments  4,  5,  and  6;  then  as  identifier  p  is  updated  (line  5),  X  and  N  remain  constant.  On  the  first 
iteration  of  the  inner  loop,  X  and  N  have  1  and  4  as  their  values,  respectively.  If  the  is  current 
declaration  was  not  used,  the  values  of  x  and  n  would  be  updated  (i.e.,  be  bound  to  each  value  in 
the  stream)  for  each  iteration  of  the  inner  loop,  not  the  outer  loop,  which  is  desired.  The  graphi¬ 
cal  icon  used  to  represent  the  it  current  declaration  is  shown  in  Figure  4.14. 

4.3.5.  User-defined  Functions 

When  a  programmer  defines  a  function  in  PDL  the  programmer  is  really  defining  a  new 
filter  which  behaves  like  the  special  filters  of  the  language.  The  function  continuously  accepts 
input,  performs  an  operation  upon  the  input,  and  produces  a  new  stream  of  result  values.  Func¬ 
tions  are  allowed  to  be  either  pointwise  or  non-pointwise  in  their  operation.  Functions  are  defined 
using  the  basic  expressions  and  program  constructs  described  in  Section  4.2  along  with  the  special 
filters. 

4.4.  Features  Taken  from  Id 

As  stated  in  Section  4.2,  Val  and  Id  are  similar  in  content  and  have  many  of  the  same 
language  features.  For  this  reason,  only  one  language  feature  was  taken  exclusively  from  Id,  the 
apply  operator.  The  operator  allows  run-time  bindings  of  procedure  definitions  to  its  parameters 
to  be  performed.  The  reason  for  the  apply  operator’s  inclusion  in  PDL  is  that  the  operator  allows 

_ L_ 

\  is  current 

V— r 

Figure  4-14  *  graphical  representation  of  the  is  current  declaration 
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run-time  identification  of  procedures  to  be  applied  on  argument  lists.  Thus,  several  run-time 
bindings  of  a  procedure  definition  are  possible. 

The  graphical  representation  of  the  Apply  operator  is  shown  in  Figure  4.15.  The  apply  icon 
utilizes  two  input  arcs,  one  of  which  is  a  fat  arc,  and  one  output  arc,  which  is  also  a  fat  arc.  The 
first  input  arc  carries  a  function  definition  while  the  second  (fat)  arc  carries  the  input  parameters. 
The  output  arc  carries  the  result  values  which  are  computed  by  ” applying”  the  function  definition 
to  the  input  tuple.  One  function  definition  can  be  applied  to  several  sets  of  input  parameters  by 
using  one  apply  function  box  for  each  set  of  input  values. 

4.5.  Motivations 

PDL  was  designed  for  experimentation  with  writing  parallel  code  in  the  form  of  dataflow 
programs.  The  language  serves  as  a  prototype  language  from  which  future  designers  can  formu¬ 
late  new  languages  by  adding  new  features  or  deleting  existing  ones.  Since  the  language  supports 


Figure  j.15-  graphical  representation  of  the  Apply  Operator 


both  graphical  and  textual  representations  for  programs,  it  is  expected  that  the  language  will  have 
only  positive  effects  for  programmers. 

Several  design  goals  were  followed  in  the  formulation  of  the  language.  These  were  discussed 
in  Section  4.1.  The  features  incorporated  from  Val  form  a  core  language  which  could  he  extended 
with  new  language  features.  Using  Val  as  the  core  language  has  helped  PDL  achieve  two  of  its 
design  goals:  abstraction  and  extensibility.  Many  of  Val’s  language  features  which  were  incor¬ 
porated  into  PDL’s  design  facilitate  the  use  of  abstraction.  The  functionality  in  Val  allows  PDL 
to  use  abstraction  icons,  to  represent  each  language  feature.  Programmers  need  not  be  concerned 
about  the  execution  details  of  a  function  or  language  construct  after  they  have  been  defined,  only 
what  the  function  or  language  construct  does.  The  use  of  Val  as  a  core  language  also  helped  PDL 
to  achieve  the  design  goal  of  extensibility.  Several  extensions  have  been  made  to  the  features 
incorporated  from  Val.  These  include  Lucid’s  filters  and  streams,  and  Id’s  apply  operator. 

Lucid’s  filters  and  streams  were  incorporated  into  the  design  of  PDL  for  two  reasons.  First, 
the  use  of  streams  and  the  special  filters  allows  PDL  to  exhibit  history  sensitivity.  Because  PDL 
exhibits  history  sensitivity,  the  language  can  be  used  for  real  time  programming,  if  desired.  The 
second  reason  for  the  use  of  Lucid’s  filters  and  streams  is  that  their  use  potentially  increases  the 
amount  of  parallel  computation  in  a  PDL  program.  All  filters  can  act  in  parallel  and  asynchro¬ 
nously.  Filters  which  require  input  from  another  filter  do  not  have  to  wait  for  the  filter  to  process 
the  whole  stream  before  it  can  begin  executing.  A  programmer  does  not  have  to  be  concerned 
about  the  rate  at  which  two  filters  process  and  produce  data  items.  Also,  all  tokens  in  a  stream 
may  be  processed  simultaneously  if  there  are  no  data  dependencies  between  the  tokens. 

Id’s  apply  operator  was  incorporated  into  the  design  of  PDL  to  allow  the  run-time 
identification  and  binding  of  a  procedure  to  its  parameters.  Several  run-time  bindings  of  a  pro¬ 
cedure  are  possible.  Also,  run-time  decisions  can  be  made  to  determine  which  procedure  to  apply 
to  an  argument  list. 


Some  experimentation  must  be  performed  on  the  language  before  an  assessment  of  its  full 
potential  for  application  can  be  made.  Since  the  language  serves  as  a  prototype  language  for 
future  development,  the  language  is  expected  to  evolve  until  an  optimal  language  is  found.  A  for¬ 
mal  specification  of  PDL  has  been  developed  to  aid  future  users  and  designers  in  their  utilization 
of  the  language.  The  next  chapter  presents  the  specification  technique  which  was  used  to  for¬ 
mally  describe  PDL. 


CHAPTER  5 


Specification  of  PDL 


5.1.  Introduction 

In  this  chapter,  the  formal  specification  of  PDL  is  described.  The  specification  incorporates 
the  three  specification  techniques  introduced  in  Chapter  3  to  describe  the  graphical  representa¬ 
tion,  textual  syntax,  and  semantics  of  the  language  constructs.  These  three  descriptions  are  com¬ 
bined  in  a  data  structure  as  described  in  Section  5.2.  Mallgren’s  algebraic  specification  technique 
is  used  to  formally  describe  the  graphical  icons  used  in  the  language.  In  Section  5.3,  the  graphical 
data  type  used  to  describe  the  function  nodes  of  PDL  is  described.  In  Section  5.4,  the  BNF  gram¬ 
mar  used  to  describe  the  textual  syntax  of  PDL  is  discussed.  In  Section  5.5,  the  specification  of 
the  semantics  of  each  language  construct  is  discussed. 

5.2.  Specification  Model 

Three  specification  techniques  are  utilized  to  define  the  semantics,  graphical  representation, 
and  textual  syntax  of  each  of  PDL’s  syntactic  constructs.  A  data  structure,  the  form  of  which  is 
shown  in  Figure  5.1,  is  used  to  describe  the  complete  specification  of  each  of  PDL’s  syntactic  con¬ 
structs.  A  brief  discussion  of  each  component  of  the  data  structure  follows. 

The  names  component  defines  which  language  constructs  (language  defined  operations  or 
program  constructs)  are  described  by  the  data  structure.  A  data  structure  may  define  more  than 
one  of  PDL’s  constructs.  The  name  of  each  construct  defined  by  the  data  structure  must  be  given 
in  the  names  component  of  the  data  structure.  A  language  construct  name  cannot  appear  in  more 
than  one  data  structure. 
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data  structure  <name> 

{ 

names:  construct  names; 
semantics:  semantic  description  of  construct 
graphics:  reference  to  graphical  description 
textual:  reference  to  BNF  description  of  construct 

} 


Figure  5.1  -  data  structure  for  defining  an  operation 


The  semantics  component  defines  the  behavior  of  the  language  construct  in  terms  of  an 
axiomatic  description.  The  semantics  component  defines  the  number  of  input  values  used  and 
output  values  produced  by  the  constructs  described.  The  component  also  defines  the  transforma¬ 
tions  performed  on  the  input  values  to  produce  the  output  values. 

The  graphics  component  makes  a  reference  to  a  procedural  description  which  defines  how  to 
draw  the  icons  representing  the  language  construct.  A  graphical  data  type  (tree  structured  node) 
and  its  operations  are  used  to  create  and  manipulate  program  graphs. 

The  textual  component  gives  a  reference  to  the  grammar  rule  in  the  BNF  grammar  which 
defines  the  syntax  of  the  language  constructs  defined  by  the  data  structure.  The  BNF  grammar 
gives  the  textual  symbol  that  is  used  for  an  operation.9 

Each  component  of  the  specification  will  now  be  described  in  detail.  A  complete 
specification  of  the  graphical  representation,  syntax,  and  semantics  of  the  language  is  presented  in 
Appendix  B,  C,  and  D,  respectively.  An  example  of  a  complete  specification  of  a  primitive  opera¬ 
tion  and  compound  program  construct  will  be  given  at  the  end  of  this  chapter. 


8  For  primitive  operations,  an  icon  can  be  labeled  with  either  the  name  of  the  operation  it  denotes,  or  the  symbol 
used  for  that  operation. 


5.3.  Graphical  Specification 


The  graphical  specification  utilizes  the  algebraic  specification  of  graphical  data  types  to 
describe  the  components  of  the  graphical  dataflow  programming  language.  A  new  graphical  data 
type,  Tree-Structured  Node  (tnode),  is  defined  to  describe  the  nodes  and  arcs  of  a  dataflow  pro¬ 
gram  graph. 

Tnodes  are  ordered  tree  structured  program  graphs  which  contain  functional  nodes  (primi¬ 
tive  or  user-defined)  and  arcs.  Tnodes  are  constructed  with  the  help  of  data  types  point ,  string 
and  name  incorporated  from  Mallgren’s  workjMALL82j .  Data  type  point  corresponds  to  a  point 
on  the  screen.  Data  type  name  is  a  collection  of  constant  names.  Data  type  string  is  a  sequence 
of  characters. 

Simple  tnodes  contain  the  primitive  function  nodes  of  the  language  and  arcs  connecting  the 
nodes.  All  nodes  and  arcs  have  a  name  or  label  that  is  supplied  by  the  programmer.  Tnodes  also 
have  programmer  supplied  names.  More  complex  tnodes  are  constructed  by  allowing  tnodes  to 
contain  other  tnodes  (user-defined  sub-graphs),  called  progeny,  as  well  as  primitive  nodes  and  arcs. 
An  inserted  progeny  is  viewed  as  a  single  node  in  the  tnode.  The  extend  operation  is  used  *o  view 
the  progeny’s  corresponding  sub-graph.  Each  primitive  function  node  in  a  tnode  has  a  unique 
name,  but  two  distinct  tnodes  may  contain  primitive  function  nodes  with  the  same  name. 

The  data  type  Tnode  and  its  operations  are  shown  in  Figure  5.2.  Each  operation,  and  the 
mapping  of  its  domain  to  its  range,  is  defined  below.  The  operations  are  split  into  the  basic  gen¬ 
erators,  generators,  and  inquiry  operations  (as  described  in  Section  3.1).  The  basic  generators 
include  the  nullnode,  moveto,  put_node,  arc_to,  and  text  operations.  The  operations  preceded  by 
a  •  are  the  basic  generators.  The  operation  preceded  by  a  *  is  a  hidden  operation  which  the  user 
cannot  use  when  creating  program  graphs. 


Tree-Structured  Node  (tnode, tp) 


nullnode 

name  =» 

tnode 

moveto 

tnode  X  point  =» 

tnode 

put_node 

tnode  X  ds_name  X  name  => 

tnode 

arc_to 

tnode  X  name.int  X  name.int  X  name  =» 

tnode 

text 

tnode  X  string  =» 

tnode 

curpos 

tnode  =» 

point 

replace_node 

tnode  X  name  X  name  =* 

tnode 

remove_node 

tnode  X  name  =» 

tnode 

remove_arc 

tnode  X  name  =» 

tnode 

expand 

tnode  X  name  => 

tnode 

display 

tnode  => 

picture 

Figure  5.2-  data  type  Tree-Structured  Node 


function  nullnode( n:name):  tnode 

Empty  user-defined  function  nodes  are  created  by  the  nullnodc  operation. 


function  mov«to(N:tnode,  p:point):  tnode 

The  current  position  becomes  point  p. 


function  p«<_node(N:tnode,  d:ds_name?  n:name):  tnode 

Put_node  inserts  a  node  with  name  n  at  the  current  position  in  dataflow  graph  N. 
Parameter  d  makes  a  reference  to  the  specific  data  structure  that  the  icon  being 
inserted  denotes.  The  data  structure  utilizes  another  reference  to  a  procedural 
description  which  defines  how  the  icon  is  drawn.  The  ds_name  of  all  language 
operations  is  the  name  of  the  data  structure  which  defines  the  operation.  The 
ds_name  of  all  program  constructs  is  the  name  of  the  data  structure  which  defines 
the  construct.  The  ds  name  of  a  user-defined  function  is  the  name  of  the  function. 


function  are_to(N:tnode,nl  :name.x,n2:name.y,n:name):tnode 


Arc_lo  draws  an  arc  from  the  xth  output  connector  of  node  nl  to  the  yth  input 
connector  of  node  n2.  The  new  arc  is  given  name  n.  The  current  position  is  not 
changed. 


function  tez*(N:tnode,  s:string):  tnode 

Text  inserts  the  pictorial  representation  of  string  s  starting  at  the  current  position. 
The  current  position  does  not  change. 


function  r«p/aee_node(N:tnode,nl:name,n2:name,d:ds_name):tnode 

Replace_nodc  replaces  node  nl  with  node  n2.  The  data  structure  used  to  describe 
node  n2  is  specified  by  d. 


function  remove_norfe(N:tnode,  n:name):  tnode 

Remove_node  removes  all  nodes  named  n  from  tnode  N.  If  there  are  no  nodes 
named  n,  the  value  of  N  is  returned  unchanged. 


function  remove_are(N:tnode,  n:name):  tnode 

Rcmovc_arc  removes  all  arcs  named  n  from  tnode  N.  If  there  are  no  arcs  named 
n,  the  value  of  N  is  returned  unchanged. 


function  ezpan</(n:name):  tnode 

Expand  takes  a  single  abstraction  icon  (node)  n  and  expands  the  node  into  its 
corresponding  sub-graph.  If  node  n  is  not  a  abstraction  icon,  no  expansion  will 
occur. 


function  curpoe(N:tnode):  point 

Curpos  returns  the  current  position  of  N. 

This  new  data  type  is  combined  with  several  of  the  types  presented  by  Mallgren  [MALL82] 
to  form  the  complete  graphical  specification  of  PDL.  The  types  incorporated  from  Mallgren’s 
work  include  point,  name,  string,  region,  user  interaction,  and  continuous  picture.  An  explanation 
of  the  uses  of  these  data  types  can  be  found  in  [MALL82  and  MAL82b]  and  is  not  given  here. 

5.4.  Textual  Specification 

Since  most  of  the  syntax  of  the  language  is  extracted  from  Val,  the  BNF  grammar  presented 
in  [ACKE79]  is  adapted  for  PDL.  One  modification  of  Val’s  syntax  was  converting  the  notation 
used  for  all  operations  from  infix  to  prefix.  Some  additional  syntactic  categories  were  added  to 
the  BNF  grammar  to  describe  the  language  features  incorporated  from  Lucid  and  Id.  The  main 
syntactic  category  used  in  the  grammar  is  the  multi-expression  (multi-exp).  Since  program  con¬ 
structs  are  translated  into  a  graphical  base  language  representation  which  utilize  run-time  decision 
nodes  (i.e.,  merge  and  switch),  grammar  rules  for  these  nodes  are  not  needed  and  are  not  given. 

5.5.  Semantic  Specification 

The  specification  of  the  semantics  of  the  language  utilizes  a  form  of  axiomatic  specification 
to  describe  each  language  feature  supported  by  the  language.  Axioms  are  used  to  describe  the 
primitive  operations,  special  filters,  and  run-time,  data-dependent  operations  of  PDL.  Rules  of 
inference  are  used  to  describe  PDL’s  program  constructs.  The  notation  used  for  the  axioms  and 
rules  of  inference  will  now  be  described. 

5.5.1.  Notation  for  Axioms 

Many  of  PDL’s  operations  act  on  several  data  types.  Since  the  semantic  description  is 
always  identical  for  all  data  types  the  operation  acts  upon,  one  semantic  description  is  used  to 


specify  each  operation.  The  semantic  description  states  which  data  types  are  acceptable  as  inputs 
to  the  operation,  the  name  of  the  operation  (for  a  certain  data  type),  and  the  axiomatic  descrip¬ 
tion  of  the  operation.  The  semantic  description  is  of  the  form: 


FOR_TUPLE  <  tuple  of  variables > 

BOUND  TO_TUPLES  <  tuple  list  > 

IN  <  axiomatic  description  > 

where  the  tuple  list  consists  of  several  tuples  of  the  form  (data  type . data  type, operation 

name).  The  operation  name  is  the  name  that  a  programmer  can  use  to  label  a  node  in  the 
dataflow  program  graph.  The  data  types  define  the  type  of  the  tokens  that  the  operation  acts 
upon. 

The  description  states  that  the  variables  in  the  tuple  of  variables  are  bound  to  the  data  type 
and  operation  values  in  one  tuple  of  the  tuple  list.  The  tuple  of  variables  are  then  utilized  in  the 
axiomatic  description  which  specifies  the  semantics  of  the  operation.  An  example  of  a  tuple  list  is 
given  in  Figure  5.3.  The  variables  VT  and  OPNAME  are  bound  to  the  values  in  one  of  the  tuples 
in  the  tuple  list.  The  tuple  list  has  two  tuples,  one  for  data  type  integer  and  one  for  type  real. 
Each  tuple  of  bound  variables  is  used  in  the  axiomatic  description  of  the  operation  to  form  a 
specific  axiomatic  description  for  the  data  type  of  the  tuple.  The  axiomatic  description  utilizes 
the  same  form  as  that  used  for  Hoare’s  axiom  which  was  introduced  in  Chapter  3. 


FOR_EACH_TUPLE  (int,int_add),  (real,real_add) 
BOUND_TO_TUPLE  (VT, OPNAME) 

IN  (axiomatic  description) 

Figure  5.8-  example  of  a  tuple  list  for  add  operations 


A  dataflow  operation  can  be  performed  when  each  arc  (or  a  combination  of  arcs)  has  a  token 
with  a  valid  type  and  when  no  arc  carries  a  token  with  the  error  value.  Some  operations  have 
other  conditions  which  must  be  true  for  the  operation  to  fire.  If  all  conditions  have  been  satisfied, 
the  operation  executes  by  performing  some  transformation  upon  the  input  tokens  and  producing 
output  tokens.  When  an  operation  (node)  has  finished  firing,  the  input  arcs  are  empty  and  a 
token  with  a  valid  type  is  carried  on  the  output  arc(s). 

The  axioms  which  are  used  to  describe  operations  have  the  form: 

<  PREC  >  (OPNAME(inputs)}  <  POSC  > . 

where  <PREC>  are  the  pre-conditions  which  must  be  satisfied  and  <POSC>  are  the  post¬ 
conditions  which  will  be  true  after  an  operation  has  executed.  The  pre-conditions  of  the 
axiomatic  description  test  for  the  conditions  that  must  be  satisfied  for  the  operation  to  fire.  Pre¬ 
conditions  also  test  for  a  valid  arc  configuration.  Arc  configurations  consist  of  the  types  of  the 
tokens  that  must  be  present  on  an  arc  before  and  after  the  operation  has  fired.  Each  input  arc  is 
denoted  by  I#  where  is  the  input  arc  number.  Arc  configurations  have  the  form: 

<I,:type . IB:type;0,:type,  ...  ,On:type> 

where  the  types  of  the  input  and  output  arcs  are  listed  in  order  (i.e.,  input  arc  one  is  listed  first, 
input  arc  two  is  listed  second,  and  input  arc  n  is  listed  nth).  The  input  arc  types  are  separated 
from  the  output  arc  types  by  a  semicolon.  Each  arc  type  in  the  arc  type  lists  are  separated  by  a 
comma.  For  example,  <1  :VT,I,,:VT;E>,  where  VT  denotes  an  integer,  states  that  input  arcs  one 
and  two  must  carry  a  token  of  type  integer  and  the  output  arc  is  empty. 

The  execution  description  gives  the  name  of  the  operation  and  the  inputs  used  by  the  opera¬ 
tion.  The  OPNAME  is  the  name  of  the  operation  as  specified  by  the  language  definition. 


The  post-condition  describes  the  arc  configuration  and  any  other  conditions  that  are  true 
after  the  operation  has  fired.  The  arc  configuration  uses  the  same  notation  as  the  arc 
configuration  in  the  pre-condition.  The  post-condition  arc  configuration  also  defines  what  values 
will  be  present  on  the  output  arcs  after  an  operation  has  fired.  These  values  may  be  expressed  in 
terms  of  the  values  that  were  on  the  input  arcs. 

An  example  of  a  axiom  for  the  addition  operation  is  shown  in  Figure  5.4.  The  axiom  states 
that  if  each  arc  carries  a  token  of  type  VT  and  the  output  arc  is  empty,  then  the  output  of  the 
operation  will  be  the  addition  of  the  two  input  values. 

Two  global  axioms  are  used  to  describe  the  behavior  of  operations  when  an  error  value  or  an 
invalid  input  appears  on  an  arc.  The  first  axiom  states  that  if  an  error  value  is  present  on  any 
input  arc  of  an  operation,  the  operation  produces  an  error  value  of  the  appropriate  type.  The 
second  axiom  states  that  if  a  value  of  an  input  arc  is  invalid,  then  the  operation  will  produce  an 
error  value  of  the  appropriate  type. 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_add),  (real,real_add) 

IN 

<I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;I1  +  I2:VT> 

Figure  5.4  -  example  of  an  axiom  for  odd  operations 


5.5.2.  Notation  for  Rules  of  Inference 


Rules  of  inference  are  used  to  specify  the  language  constructs  of  PDL.  Each  rule  of  infer¬ 
ence  has  the  form: 

FOR_EACH  (list  of  variables) 

BOUND_TO_ONE_OF  (list  of  types) 

IN 

H„  ,H0 
H 

where  the  H  ,  ...  ,Hn  are  previously  proven  axioms  and  H  is  the  axiom  which  is  being  proven 
correct.  Axioms  H  gives  the  syntactical  statement,  pre-conditions,  and  post-conditions  of  the  pro¬ 
gram  construct.  Each  axiom,  H(,  ...  ,Hn,  uses  the  same  notation  discussed  in  Section  5.5.1.  The 
pre  and  post  conditions  of  axiom  H  give  the  valid  arc  configurations  of  the  construct  along  with 
any  other  conditions  which  are  true  before  or  after  the  construct  fires.  An  example  of  a  rule  of 
inference  for  the  forall  construct  is  shown  in  Figure  5.5. 


FOR_EACH(VT1  ,VT2,VTq) 

BOUND_TO_ONE_OF(int, real, bool, char, array, record, union, function) 

IN 

<i:int.I,:VT1 . In:VTn;E1>{S,}<E1 . En;0|:VT2>  A  (L<i<U), 

_ F  €  {plus, mult, and, or, min, max} _ 

Cl^VT, . In:VTn;E> {forall  i  in  jL.U|  do  S, eval:F}<E, . En;F(01,F(02,...,F(0u.[y0l.H^I)...)):VTj> 

Figure  5.5-  rule  of  inference  for  the  forall  construct 


5.0.  An  Example 

An  example  of  a  complete  specification  of  an  operation  and  a  language  construct  will  be 
presented  in  this  section.  The  data  structure  which  is  used  to  specify  the  add  operations  of  PDL 
is  shown  in  Figure  5.6.  The  name  of  the  operations  which  the  structure  is  used  to  specify  include 
the  int_add  and  real_add  operations.  The  xernantir*  component  of  the  structure  gives  the  axiom 


which  is  used  to  specify  the  operations.  The  graphics  component  gives  a  reference  to  the 
draw_add_node  procedure  which  draws  the  correct  icon.  Finally,  the  textual  component  gives  the 
correct  textual  syntax  used  for  the  operation. 

The  data  structure  used  to  specify  the  forall  construct  of  PDL  is  shown  in  Figure  5.7.  The 
semantics  component  of  the  structure  gives  the  rule  of  inference  used  to  specify  the  construct. 
The  graphics  component  gives  a  reference  to  a  executable  procedure  which  draws  the  abstraction 
icon  used  to  represent  the  construct.  Finally,  the  textual  component  gives  a  reference  to  the 
grammar  rule  in  the  BNF  grammar  which  describes  the  forall  construct. 

Appendix  B  gives  the  complete  specification  of  the  semantics,  syntax,  and  graphical 
representation  of  PDL. 


data  structure  add_node 

{ 

names:  int_add,  real_add; 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO_TUPLES  (int,int_add),  (real,real_add) 

IN 


<I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;I1  +  I2:VT> 

graphics:  draw_add_node; 
textual:  +(I1,I2); 

} 


Figure  5.6  -  example  of  data  structure  for  add  operation 
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forall_eval_node 

{ 

names:  forall_eval 
semantics: 

FOR.EACHtVTj  ,VT2,VTd) 

BOUND_TO_ONE_OF(int, real, bool, char,  array, record, union, function) 
IN 


<i:int,I1:VT1,...,I11:VTB;E1>{S,}<E1 . E„;Ol:VT2>  A  (L<i<U), 

_ F  6  (plug, mult, and, or, min, max) _ 

<l,:VT, . I„:VTn;E> {for&ll  i  In  [L,U]  do  S,eval:F}<E, . EB;F(01,F(012,...,F(0u_L>0lM^1)...)):VT2> 

graphics:  draw_forall_node; 
textual:  forall_expr 
} 


Figure  5.7  -  example  of  a  data  structure  for  forall  construct 


CHAPTER  6 


Summary,  Conclusions,  and  Suggestions  for  Future  Work 


6.1.  Summary  and  Conclusions 

In  this  thesis,  the  formal  specification  of  the  prototype  dataflow  programming  language, 
PDL,  that  supports  both  graphical  and  textual  representations  of  programs  has  been  presented. 
PDL  serves  as  a  core  language  which  is  expected  to  evolve.  Future  designers  can  add  new  or 
delete  existing  features  to  obtain  an  optimal  language.  The  specification  technique  developed 
allows  designers  to  add  new  features  by  defining  the  semantics,  textual  representation,  and  graphi¬ 
cal  representation  for  the  added  features.  The  language  supports  an  applicative  programming 
style  (incorporated  from  Val  and  Id)  which  is  augmented  by  Lucid’s  streams  and  filters. 

Several  conclusions  are  made  concerning  PDL  and  its  formal  specification.  First,  we  are 
convinced  that  PDL  meets  its  design  goals.  PDL  supports  the  simultaneous  existence  of  graphical 
and  textual  representations  for  all  language  constructs.  The  use  of  both  representations  is 
expected  to  have  a  positive  effect  on  the  programming  process;  the  only  disadvantage  will  be  the 
time  required  to  learn  how  to  merge  the  representations  into  a  useful  programming  tool.  At  each 
stage  of  program  development,  a  programmer  could  write  a  program  using  the  type  of  representa¬ 
tion  that  is  most  convenient  for  writing  that  part  of  the  program.  The  use  of  graphics  in  pro¬ 
gramming  can  only  have  positive  effects,  not  just  for  dataflow  programming,  but  for  programming 
in  general. 

The  design  of  PDL  places  no  barriers  on  extensibility.  Since  PDL  adopts  a  graphical  base 
language,  new  language  constructs  can  be  incorporated  into  the  language  by  assuring  the  con¬ 
structs  can  be  translated  into  graphical  base  language  equivalents.  A  new  data  structure  which 


defines  the  textual  syntax,  graphical  representation,  and  semantics  of  the  new  construct  would 
need  to  be  introduced.  Since  PDL  serves  as  a  prototype,  the  language  is  expected  to  evolve.  The 
extensibility  of  PDL  can  be  found  in  many  of  its  language  features.  Several  examples  of  how  the 
language  can  be  extended  include  the  relaxation  of  the  strong  typing  used  in  PDL  and  allowing 
the  eval  and  construct  expressions  to  appear  in  a  forall  loop  together. 

As  another  result  of  using  a  graphical  base  language,  the  idea  of  abstraction  can  be  adopted 
naturally  in  PDL’s  design.  Each  language  construct  can  be  represented  by  a  single  icon  where 
appropriate.  Once  the  lower  level  base  language  program  graph  has  been  defined,  the  program¬ 
mer  can  utilize  an  abstraction  icon  to  represent  the  graph.  A  programmer  may  also  utilize 
programmer-defined  abstraction  icons. 

The  second  conclusion  concerns  the  formal  specification  of  PDL.  Since  the  technique  incor¬ 
porates  three  formal  techniques  to  define  the  language,  the  technique  is  also  formal  and  can  be 
used  for  formal  reasoning.  The  main  goal  of  developing  the  specification  was  to  provide  language 
implementors  with  an  unambiguous  and  precise  description  of  the  language  so  that  the  language 
could  be  implemented  on  a  graphical  workstation.  Since  Hoare’s  axiomatic  specification  technique 
was  used  to  define  the  semantics  of  the  language,  the  specification  can  also  be  used  for  formal  rea¬ 
soning  about  programs  written  in  the  language. 

The  use  of  an  axiomatic  specification  technique  to  describe  the  semantics  of  PDL  is  interest¬ 
ing  because  axiomatic  definitions  describe  th  state  of  program  variables  before  and  after  the  exe¬ 
cution  of  a  program  statement.  PDL  describes  the  state  of  arcs  before  and  after  the  execution  of 
program  expressions.  The  states  of  the  arcs  are  expressed  as  the  pre  and  post  conditions  of 
axioms. 

Because  of  the  rigorous  manner  in  which  the  semantics  of  PDL  were  specified,  the  final 
semantics  of  PDL  evolved  in  a  positive  manner  through  numerous  interactions  with  committee 
members.  As  the  semantics  were  defined,  we  were  forced  to  discover  the  unambiguous  and  precise 
semantics  of  all  language  constructs. 


0.2.  Suggestions  for  Future  Work 

PDL  was  designed  for  experimentation  with  writing  parallel  code  in  the  form  of  dataflow 
programs.  The  proof  of  the  work  performed  in  the  thesis  work  will  only  come  with  the  implemen¬ 
tation  of  PDL  on  a  graphical  workstation  environment  and  the  development  of  translation 
mechanisms  to  translate  PDL  programs  into  code  that  can  run  on  parallel  host  machines.  Once 
PDL  has  been  implemented,  an  evaluation  of  the  language  should  be  performed.  Thus,  three 
areas  of  future  work  are  noted. 

The  first  area  of  future  work  is  the  implementation  of  the  language  and  the  development  of 
a  graphical  workstation  environment.  Work  has  begun  at  the  University  of  Southwestern  Louisi¬ 
ana  to  develop  such  a  programming  environment.  To  date,  no  implementation  of  the  language  or 
a  graphical  work  station  environment  has  been  finished.  This  implementation  would  include 
developing  a  mapping  mechanism  between  the  graphical  and  textual  representations  of  the 
language. 

After  the  development  of  a  programming  environment  and  the  implementation  of  the 
language  on  the  environment,  an  evaluation  of  the  language  by  programmers  should  be  per¬ 
formed.  The  evaluation  would  include  the  identification  of  which  features  should  and  should  not 
be  in  the  language,  and  the  development  of  several  test  programs  on  the  programming  environ¬ 
ment.  Although  some  programs  have  been  developed  (on  paper)  using  the  language,  a  complete 
evaluation  of  PDL  is  not  possible  until  a  graphical  programming  environment  is  implemented. 

Another  area  of  future  work  is  the  development  of  a  translation  mechanism  which  would 
translate  PDL  programs  into  code  which  could  be  run  on  parallel  host  machines.  This  translation 
may  not  be  easy  and  would  depend  upon  the  primitives  supported  by  each  individual  parallel  host 
machine. 

A  final  area  of  future  work  is  the  development  of  a  translation  mechanism  which  would 
translate  PDL  programs  into  code  to  be  executed  on  the  Dataflow  Simulator  (DFSS)  which  is 
currently  on  the  Multics  system  at  the  University  of  Southwestern  Louisiana.  This  translation 
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would  be  easy  because  PDL  has  many  of  the  same  constructs  supported  by  the  base  language  of 

DFSS. 
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APPENDIX  A 


PROGRAM  EXAMPLES 


This  program  is  used  to  perform  mergesort  on  a  stream  of  integer  values.  Since  streams  are 
used,  an  array  is  not  needed  to  hold  the  elements  to  be  sorted.  The  main  function  of  the  program 
is  msort.  Function  maort  calls  function  merge  to  merge  the  elements  of  two  streams.  The 
number  of  elements  to  be  sorted  is  arbitrary. 


function  msort(a:Snt;  returns  int) 
if  =(flrst(next(a)),eod)  then  a 
else 
begin 

b:bool  :=  fby(false,not(b)); 
tl:int  :=  whenever(a,b); 
t2:int  :=  whenever(a,not(b)); 
return(merge(msort(tl),msort(t2))); 
end; 
end 


function  merge(x,y:int;  returns  int) 
if  takexx  then  return(xx)  else  return(yy)  end; 
where 

xx:int  :=  upon(x, takexx); 

yy:int  :=  upon(y,not(takexx)); 

takexx:bool  :=  if  =(yy,eod)  then  true 
else 

if  =(xx,eod)  then  false 
else 

if  <(x,y)  then  true 
else  false; 


end; 

end 


This  function  is  used  to  perform  matrix  multiplication  on  matrices  of  arbitrary  size.  (NOTE:  the 
number  of  rows  in  the  matrix  must  be  equal  to  the  number  of  elements  in  each  row.)  The  func¬ 
tion  uses  three  forall  loops  to  perform  the  multiplication.  An  array  of  arrays  is  used  to  implement 
the  matrices. 


function  matrix_mult(A,B:  array  (array  [int|],  n:int;  returns  array[array  [int]] ) 

forall  i  in  [l,nj 

construct(forall  j  in  [l,n] 

construct(  forall  k  in  [l,n] 

eval  plus  ,*(A[i] [k] »B[kj [j] ); 
end;) 

end;) 

end; 

end 


This  function  is  used  to  compute  the  factorial  of  n. 


function  fact(n:int;  returns  int) 
begin 

b:boo!l  :=  if  +(y,l)  then  true 
else  false 

x  int  :=  fby(l,*(x,y)); 
y  int  :=  fby(n,-(y,l)); 
return(fby(upon(x,booll),eod)) 
end; 
end 


APPENDIX  B 


TEXTUAL  SPECIFICATION  OF  PDL 


In  the  following  BNF  grammar,  |text|  means  that  zero  or  more  occurrences  of  the  enclosed 
text  are  allowed,  [text]  means  that  zero  or  one  occurrences  of  the  enclosed  text  is  allowed. 


Type  Specifications 


type-spec 

::=  basic-type-spec 
j  compound-type-spec 

type-name 

basic-type-spec 

::=  boolean 

[  character 

|  integer 

j  null 

j  real 

|  function 

compound-type-spec 

::=  array  [type-spec] 

|  record[field-spec  j  ;field-spec  J  ] 

|  union  [tag-spec  |;tag-spec|  ] 

field-spec 

::=  field-name  j  , field-name  j  :type-spec 

tag-spec 

::=  tag-name  j,  tag-name  j  :type-spec 

field-name 

::=  name 

tag-name 

::=  name 

tvpe-name 


name 


Type  definitions 
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type-def-part 

type-def 

type-name 


Constants 

constant  ::=  nil 
|  false 

|  true 

|  integer-number 

|  real-number 

]  character-string 

|  error(type-spec) 

|  erapty[type-spec] 


|  type-def;  |  |  |  type-def;  j  type-def 

type  type-name  =  type-spec 
name 


Expressions 

expression 

simple-expression 

term 

factor 


simple-expression 

relational-op(  expression, simple-expression) 
term 

adding-op(simple-expression,term) 

factor 

multiplying-op(  term, factor) 
primary 

unary-op(primary) 
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primary 


constant 

value-name 

invocation 

array- ref 

array-generator 

record- ref 

record-generator 

union-test 

union-generator 

error- test 

prefix-operation 

(multi-exp) 


unary-op 

+  M« 

relational-op 

r 

A I 

II II 

V  — 

-II 

V  A 

adding-op 

::  = 

+  1  -  1  II  1  cat 

multiplying-op 

::= 

*|/|  mod  |  && 

value-name 

::  = 

name 

invocation 

::  = 

function-name(multi-exf 

function-name 

::  = 

name 

array-ref 

::  = 

primary(multi-exp) 

array-generator 

[  [multi-exp:  ]  multi-exp 

primary  [  [multi-exp:  ]  multi-exp  |  ;[multi-exp:]multi-exp  | 


record-ref 


primary  .field 
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record-generator 

field-def 

field 


record[field-def  |;field-defj  ] 

replace  primary  [field:multi-exp  |  ;field:multi-exp  |  ] 

field-name:multi-exp 

field-name  ( .field-name  I 


field-name 

union-test 

union-generator 

tag-name 


name 

is  tag-name(multi-exp) 

make  type-spec  [tag-name:multi-exp] 

name 


error-test 


:=  is-error(multi-exp) 


prefix-operation 


char(multi-exp) 

int(multi-exp) 

int_c(multi-exp) 

floor(multi-exp) 

trunc(multi-exp) 

float(  multi-exp) 

abs(multi-exp) 

exp(  multi-exp) 

max(multi-exp) 

min(multi-exp) 

array(multi-exp) 

ar  ray  _low(  multi-exp) 

arr  ay  _high(  multi-exp) 

array  _size(  multi-exp) 

array  _cat(multi-exp) 

set_bounds(  multi-exp) 

first(multi-exp) 

rest(multi-exp) 

advance_upon(multi-exp) 

asa(  multi-exp) 

whenever  (multi-exp) 

concatenate(  multi-exp) 

fby(multi-exp) 

is_current(multi-exp) 

return(  multi-exp) 
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basic- multi-exp 


invocation 


::=  expression 

|  basic-multi-exp, basic-multi-exp 

j  invocation 

j  (multi-exp) 

::=  function-name(multi-exp) 


multi-exp 


Program  Structures 


basic-multi-exp 

conditional-exp 

begin-exp 

case-exp 

iteration-exp 

forall-exp 

apply-exp 


conditional-exp 

::= 

if  multi-exp  then  multi-exp 

|  elseifmulti-expthenmulti-exp  j 

else  multi-exp 
end 

begin-exp 

::= 

begin  decldef-part 
return  multi-exp 
end 

decldef-part 

|  decldef;  j 

l 

|  decldef;  |  decldef 

decldef 

. . _ 

decl 

i 

def 

1 

decl  |,decl|  :=  multi-exp 

decl 

::= 

value-name  | , value-name  |  :type-spec 

def 

::= 

value-name  j  .value-name  j  :=  multi-exp 
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case-exp 


test-expression 

tag-list 

tag-name 

iteration-exp 


iter-end 


case  test-expression 
|  tag-list:multi-exp  j 

idefault:multi-exp 
d  J 

value-name  :=  multi-exp 
tag  tag-name  | , tag-name  | 
name 

for  decldef-part  do 
if  multi-exp  then 
iter-end 
else  iter-end 
end 

if  expression  then  iter-end 

|  elseifexpressiontheniter-end  j 

else  iter-end 
end 

case  test-expression 


|  tag-list:iter-end  j 

default.iter-end 

end 


begin 
decldef-part 
return  iter-end 
end 

multi-exp 


def 


forall-exp 


forall-op 

apply-exp 

function-def 

apply-op 


& 


Function  Modules 


function-module 


forall  value-name  in  [multi-exp] 
decldef-part 

construct  expression  |  eval  forall-op  multi-exp 
end 

plus  |  times  |  min  |  max  |  or  |  and 
aPply(function-def, apply-op) 
function-module 


< 


primary  j, primary  j 


> 


function  function-name 


(jdecljj  d 
|  .type-spec  |  ) 


returns  type-spec  {  .type-spec 

type-def-part 
multi-exp 
end 


APPENDIX  C 


GRAPHICAL  SPECIFICATION  OF  PDL 


Tree-Structured  Node  (tnode,tn) 


nullnode 

name 

=> 

tnode 

moveto 

tnode  X  point 

tnode 

put_node 

tnode  X  type  X  name 

tnode 

arc_to 

tnode  X  name.int  X  name.int  X  name 

=> 

tnode 

text 

tnode  X  string 

=> 

tnode 

curpos 

tnode 

point 

replace_node 

tnode  X  name  X  name 

tnod<- 

remove_node 

tnode  X  name 

=> 

tnod<- 

remove_arc 

tnode  X  name 

tnod<- 

expand 

tnode  X  name 

=> 

tnod<- 

display 

tnode 

=3 

pirttip 

axioms 


curpos 

tnl 

tn2 

replace_node 

InS 
tnj 
tn  5 

tn6 

renu>vp_rn>de 

In  7 
In  S 
tn  fi 


fn  I  'i 
tn  1  l 


curpos(nullnode)  =  origin 
curpos(moveto(P.x))  ---  x 


replace_node(nu!!n(xie.ti  n_  i 
replace_nodc(  movi-tiW  P  \i  n  n 
replacc_riodf( put_nod*-i I’ t  n  t, 


r<-pl:n  e_l|i>.lf|  an ■_!<  I’  : 


i»f  ■  r,  •  ■ 

if 

t  l**#' 


f  ►  > 


r**ni»  -v »  _*i  •  i*  :i  .  ii  i- 

*  -  I ; »  •  \  «  '»■-!• . 

r  *  Mr  w  *  i  ■  1  *  ; 
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remove_arc 

tnl2 

tnlS 

tnl4 

tnl5 

tnl6 

expand 


remove_arc(nullnode,n)  =  nullnode 
remove_arc(moveto(P,x),n)  =  remove_arc(P,n) 
remove_arc(put_node(P,t,n1),n)  =  remove_arc(P,n) 
remove_arc(arc_U>(P>n1.i,n2.j,n3),n)  =  if  (n  =  n3)  then  P 

else  remove_arc(P,n) 

remove_arc(text(P,s),n)  =  remove_arc(P,n) 


tn22 

tn2S 

tn24 


tn25 

tn26 


expand(P,  nullnode)  =  nullnode 
expand(moveto(P,x),n)  =  expand(P,n) 
expand(put_node(P,t,n1),n)  =  if  (n  =  n,i  A  (t  =  udf)then 

draw_suDgraph(n) 
else  expand(P,n) 
expand(arc_to(P1n1.i,n2.j,n3),n)  =  expand(P,n) 
expand(text(P,s),n)  =  expand(P,n) 


display 

tn27 

tn28 

tn29 

tnSO 

tnSl 


display(nullnode)  =  p. nullnode 
display(moveto(P,x))  =  display(P) 

display(put_node(P,t,n))  =  p.sum(display(P),p.node(curpos(P),t)) 
display(arc_to(P,nj.i,n2.j,n3))  = 

p.sum(display(P),p.arc(pos(n,.i),pos(n2.i))) 
display(text(P,s))  =  p.sum(display(P),p.text(curpos(P),s)) 


Continuous  Picture  (picture, p) 
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*  •  nullpict 

*  •  inspatch 

*  domain 

*  sum 

*  addpatch 

*  restriction 


=►  picture 
picture  X  region  =»  picture 
picture  =»  region 
picture  X  picture  =>  picture 
picture  X  region  =»  picture 
picture  X  region  =»  picture 


axioms 

pi  domain(nullpict)  =  nuilregion 

p2  domain(inspatch(P,R))  =  Rll  domain(P) 

pS  sum(P, nullpict)  =  P 

P4  sum(Pi,inspatch(P2,R))  —  sum(adddpatch(Pt,R),restriction(P2,~R)) 
p5  addpatch(nullpict,R)  =  inspatch(nullpict,R) 

p6  addpatch(inspatch(P,Ri),R2)  = 

inspatch(inspatch(addpatch(P,R2-R1),Rl-R2),R1  fl  Rjj) 
p7  restriction(nullpict,R)  =  nullpict 

p8  restriction(inspatch(P,Ri),R2)  =  inspatch(restriction(P,R2),R,  (~l  R2) 

p9  inspatch(P, nuilregion)  =  P 

plO  inspatch(inspatch(P,Rl),R2)  =  inspatchfP.R,  U  R2) 

User  Interaction  (ip) 


program  operations 


prompt 

string 

getkey 

char 

getposn 

point 

getpick 

name 

post 

tnode  X  name 

unpost 

name 

=* 

user  actions 

getprompt 

string 

keystroke 

char 

position 

point 

pick 

point 

boolean 

auxiliary  functions 

*  postpict 

state 

-» 

tnode 

*  pickname 

state  X  point 

name 

*  image 

state 

picture 
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axioms 


getkey 

ipl 

ip2 

ipS 

'P4 

ip5 

getposn 
ip  6 
ip  7 
ip8 
ip  9 
ip  10 

getpick 
ip  11 
ip  12 
ip  IS 
ipl4 
ip  15 

getprompt 
ip  16 
ip  17 
ip  18 
ip  19 
ip  20 


pick 

ip  21 


ip22 
ip  2  3 


ip24 


wait(linit)  =  true 
wait(getkey$return(S))  =  true 
wait(keystroke$return(S,c))  =  false 
value(linit)  =  undefined 
value(keystroke$return(S,c))  =  c 


wait($init)  =  true 
wait(getposn$return(S))  =  true 
wait(position$return(S,p))  =  false 
value($init)  =  undefined 
value(position$return(S,p))  =  p 


wait(Sinit)  =  true 
wait(getpick$return(S))  =  true 

wait(pick$return(S,p))  =  ->p.visible(image(S),rg.pickregion(p)) 
value($init)  =  undefined 
value(pick$retum(S,p))  =  pickname(S.p) 


wait(Sinit)  =  true 
wait(prompt$return(S,s))  =  false 
wait(getprompt$return(S))  =  true 
valvie($init)  —  nullstring 
value(prompt$return(S,s))  =  s 


value(S,p)  =  -’p.visible(image(S),rg.pickregion(p)) 
postpict($init)  =  tp.nullpict 

pickname(S.p)  =  if  s.empty(tp.picknames(postpict(S),rg.pickregion(p)) 
then  n.null 

else  s.first(tp.picknames(postpict(S),rg.pickregion(p))) 
image(S)  =  tp.display(postpict(S)) 
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Region  (region, rg) 


* 


null 

region 

region 

universe 

region 

lineseg 

point  X  point 

=* 

region 

box 

point  X  point 

=» 

region 

complement 

region 

region 

intersect 

region  X  region 

=» 

region 

union 

region  X  region 

region 

difference 

region  X  region 

=4 

region 

empty 

region 

=► 

boolean 

contains 

region  X  region 

=» 

boolean 

contains 

ptregion  X  point 

boolean 

equal 

region  X  region 

=» 

boolean 

pickregion 

point 

=> 

region 

axioms 


object  mapping 

rgl 

rgZ 

rgS 

rg\ 

rg5 

rg6 

rg7 

rg8 

rg9 

rglO 

rgll 

rgl2 

rglS 


nullregion  «  {  } 

universe  (q  |  q  is  in  the  universe} 
lineseg(qi,q2)  «  {(x,y)  |  x,  <x<x2(y,  <y  <y2, 

(y2-yi)*(x2-x,)Xy  =  XiXy2-x2Xy,} 
boxlq^cb)  {(x,y)|Xi<x<x2ly,<y<y2} 
complement(R)  <=w  ~  (R'  ) 
intersec^R,^)  R/  n  R2' 
union(Rl,R2)  R,'  U  R2' 
difference(R1,R2)  R/  -  R^ 
empty(R)  =  (R'  =  {  }) 
contains^, R2)  =  R2'  C  R,' 
containspt(R,q)  =  q€  R' 
equal(R,,R^)  =  (R,'  =  R2'  ) 
pickregion(q)  s=»  {q} 


j 


Point  (point, pt) 


point 

real  X  real 

=> 

point 

polarpt 

real  X  real 

=» 

point 

origin 

=» 

point 

absissa 

point 

real 

ordinate 

point 

=> 

real 

radius 

point 

real 

angle 

point 

=» 

real 

sum 

point  X  point 

point 

difference 

point  X  point 

point 

axioms 

ptl  polarpt(x!,x2)  =  point(x|*cos(x2),x1Xsin(x2)) 

pt2  origin  =  point(0,0) 

ptS  abscissa(point(x1,x2))  =  x, 

pt4  ordinate(  point(x !  ,x2))  =  x2 

pt5  radius(point(x,,x2))  =  (x,2  +  x2  f1 

pt6  angle(p)  =  if  radius(p)  =  0  then  0 

elseif  ordinate(p)>0 
then  arccos(abscissa(p)  radius(p)) 
else  360  -  arccos(abscissa(p)-r-radius(p)) 
ptl  sum(point(x1,x2),point(x3,x4))  =  point(x1+x3lx2+x4) 

pt8  difFerence(point(x,,x2),point(x3>X4))  =  point(x1-x3,x2-x4) 


Name(name,n) 

name]  =»  name 

namem  =>  name 

equals  name  X  name  =*  boolean 

*  lessthan  name  X  name  =*  boolean 


String  (string, st) 


•  nullstr  =>  string 

•  inschar  string  X  char  =*  string 

concat  string  X  string  string 


axioms 

»tl  concat(s, nullstr)  =  s 

st2  concat^.inscharfsa.a))  =  inschar(concat(si,S2),a) 


theorems 

atlT  concat(nullstr,s)  ==  s 


APPENDIX  D 


SEMANTIC  SPECIFICATION  OF  PDL 


With  each  of  the  axioms  given  below,  it  is  assumed  that  the  inputs  are  not  the  error  value 
and  that  they  are  valid.  Two  global  axioms  are  given  to  specify  the  behavior  of  all  operations 
when  an  error  value  or  an  invalid  input  is  present  on  one  of  the  operation’s  input  arcs.  The  two 
axioms  (error  and  valid)  are  given  first. 

All  operations  act  on  streams  of  data  values.  The  manipulation  of  the  BOS  and  EOS  tokens 
is  not  shown  in  the  specifications.  It  is  assumed  that  the  programming  environment  would  mani¬ 
pulate  these  control  tokens.  The  specification  of  the  special  filters  utilizes  a  different  notation 
than  the  other  operations  to  refer  to  each  element  in  the  stream.  I.i  refers  to  the  ith  element  in 
stream  I.  Finally,  the  actions  that  operations  perform  are  machine  and  implementation  depen¬ 
dent  (i.e.,  the  addition  of  integers  and  real  numbers  is  different  on  different  computers). 


error.  The  error  axiom  states  that  if  any  of  an  operation’s  input  arcs  carry  a  token  with  the 
error  value,  the  operation  will  produce  an  error  value  with  an  appropriate  type  (the 
type  the  operation  ordinarily  produces). 


<I,:VT . ln:VT;E, . Em>  A  I,  =  error(VT,)T(l<i<n){OPNAME(I, . I„)}<E . E;error[VT|:VT . error[VT|:VT> 


valid :  The  valid  axiom  states  that  if  any  of  an  operation’s  input  arcs  carry  an  invalid  token 
(i.e.,  the  type  of  the  token  is  not  the  type  expected  by  the  operation),  the  operation 
will  produce  an  error  value  with  an  appropriate  type  (the  type  the  operation  ordinarily 
produces). 

<I1:VT,...,l„:VT;E1 . Em>  A  invalidt^.U^i^nHOPNAMEfl, . In)}<E . E;error[VT|:VT,...,error[VT|:VT> 
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add:  This  operation  accepts  and  consumes  2  input  tokens  of  type  integer  or  real  and  pro¬ 
duces  a  single  output  token  of  type  integer  or  real  which  is  the  sum  of  the  input  to¬ 
kens.  The  subtract,  multiply,  and  divide  operations  are  similar  to  the  add  operation 
in  their  specification  (except  that  a  different  operation  is  performed  on  the  input 
values). 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (int,int_add),  (real,real_add) 

IN 

<  I,  :VT,I2:VT;E  >  {OPNAME(I„I2)}  <  E.E^+I^VT  > 


subtract: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO  TUPLES  (int,int  subtract),  (real,real_subtract) 

IN 

<I1:VT,I2:VT;E>{OPNAME(I„I2)}<E,E;I1-I2:VT> 


multiply. 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int.int  multiply),  (real,real_multiply) 

IN 

<  I,  :VT,I2:VT;E  >  { OPNAME(I,  ,I2)}  <  E,E;I,  X  I2:VT  > 


divide: 


FOR.TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (int,int_divide),  (real,real_divide) 

IN 

<  I,  :VT,I2:VT;E  >  {OPNAME(I,  ,I2) }  <  E,E;I,-^I2:VT  > 


exponentiation: 

This  operation  accepts,  and  consumes  2  input  tokens  of  type  integer  or  real  and  pro¬ 
duces  a  single  output  token  of  type  integer  or  real  which  is  the  result  of  raising  the 
first  token  to  the  power  of  the  second  token. 

FOR.TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_exp),  (real,real_exp) 

IN 

<I1:VT,I2:VT;E>{OPNAME(I1>I2)}<E,E;I1l2:VT> 


modulus: 

This  operation  accepts  and  consumes  2  input  tokens  of  type  integer  and  produces  a 
single  output  token  of  type  integer  which  is  the  remainder  of  an  integer  division  of  the 
inputs.  The  first  input  is  the  dividend  of  the  division  and  the  second  is  the  divisor. 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (int,int_modulus) 

IN 

<I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;I1  mod  I2:VT> 


negation: 

This  operation  accepts  and  consumes  one  input  token  of  type  integer  or  real  and  pro¬ 
duces  a  single  output  token  of  type  integer  or  real  which  is  the  result  of  the  unary  ne¬ 
gation  of  the  input  token. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (int.int  negation),  (real, real  negation) 

IN 

<Il:VT;E>{OPNAME(I,)}<E;0  -  I,:VT> 


absolute_value: 

This  operation  accepts  and  consumes  one  input  token  of  type  integer  or  real  and  pro¬ 
duces  a  single  output  token  of  type  integer  or  real  which  is  the  absolute  value  of  the 
input  token. 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int.int  absolute),  (real,real_absolute) 

IN 


<Il:VT;E>{OPNAME(I,)}<E;|  lJ:VT> 
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maximum: 

This  operation  accepts  and  consumes  two  input  tokens  of  type  integer  or  real  and  pro¬ 
duces  a  single  output  token  of  type  integer  or  real  which  is  the  largest  of  the  two  in¬ 
put  tokens.  The  minimum  is  similar  to  the  maximum  operation  except  that  it  pro¬ 
duces  the  smallest  of  the  two  inputs. 

FOR_TUPLE  (VT.OPNAME) 

BOUND _TO  TUPLES  (int,int_max),  (real, real  max) 

IN 

(Ii  >  Ij,l<i,j<2)  A  <I1:VT,l2:VT;E>{OPNAME(I1,I2)}<E)E;Ii:VT> 


minimum: 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (int,int_min),  (real, real  min) 

IN 

(Ii  <  Ij,l<i.j<2)  A  <I,:VT,I2:VT;E>{OPNAME(I„I2)}<E,E;Ii:VT> 


equal :  This  operation  accepts  and  consumes  two  input  tokens  and  produces  a  single  output 
token.  The  input  tokens  are  either  of  type  integer,  real,  character,  or  boolean.  Both 
input  tokens  must  be  of  the  same  type.  The  output  token  is  of  type  boolean.  The 
value  of  the  output  token  is  True  if  the  input  tokens  are  equal,  False  otherwise.  The 
specification  of  the  iot_equal,  less_than,  greater_than,  greater_than_or_equal,  and 
less_than_or_equal  a.e  similar  to  the  equal  operation  except  that  different  comparisons 
are  made. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_equal),  (real,real_equal), 

(bool,bool_equal),  (char,char_equal) 

IN 

(I,  =  I2)«=*P  A  <Il:VT,I2:VT;E>{OPNAME(I„I2)}<E,E;P:Bool> 


not_equal: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_not_equal),  (real,real_not_equal), 

(bool,bool_not_equal),  (char,char_not_equal) 

IN 

(l,  jL  I2)*=»P  A  <I,:VT.I2:VT;E>{OPNAME(I1,I2)}<E.E;P:Bool> 


greater_than : 


FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_greater_than),  (real,real_greater_than), 
(bool,greater_than),  (char,char_greater_than) 

IN 

(I,  >  I2)«PA  <I1:VT,I2:VT;E>{OPNAME(I1)I2)}<E,E;P:Bool> 


less_than: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_less_than),  (real,real_less_than), 

(bool,bool_less_than),  (char,char_less  than) 

IN 

(I,  <  y«->P  A  <I,:VT,I2:VT;E>  {OPNAME(IbI2)}<E,E;P:Bool> 


greater_than_or_equal: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_greater_equal),  (real,real_greater_equal), 

(bool,bool_greater_equal),  (char,char_greater_equal) 
IN 

(Ii  >  I2)~P  A  <I1:VT,I2:VT;E>  {OPNAME(I,,I2)}  <E,E;P.Bool> 


less_than_or_equal: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_less_equal),  (real,real_less_equal), 
(bool,bool_not_equal),  (char,char_not_equal) 

IN 

(I,  <  !„)«=*  A  <I1:VT,I2:VT;E>  {OPNAME(I,,I2)}<E,E;P:BooI> 


97 


and :  This  operation  accepts  and  consumes  two  input  tokens  of  type  boolean  and  produces  a 
single  output  token  of  type  boolean.  The  value  of  the  output  token  is  the  logical  AND 
of  the  two  input  tokens.  The  specification  of  the  or  operation  is  similar  to  the  and 
operation  except  that  the  logical  OR  of  the  two  inputs  is  the  result. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (bool,bool_and) 

IN 

(I,  A  I2)<=*P  A  <I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;P:Bool> 

or: 

FOR_TUPLE  (VT,OPNAME) 

BO UND_TO .TUPLES  (bool,bool_or) 

IN 

(Ii  |  I2)<=»P  A  <I1:VT,I2:VT;E>  {OPNAME(I1,I2)}<E(E;P:Bool> 


not:  This  operation  accepts  and  consumes  a  single  input  token  of  type  boolean  and  pro¬ 

duces  a  single  output  token  of  type  boolean.  The  value  of  the  output  token  is  the  log¬ 
ical  negation  of  the  input  token. 

FOR.TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (bool.bool.not) 

IN 

<Ii:VT;E>{OPNAME(I,)}<E;~  I,:VT> 


array_create: 

This  operation  accepts  and  consumes  a  single  input  token  which  is  the  type 
specification  for  the  array  to  be  created  and  produces  an  empty  array  of  the  indicated 
type. 

FOR.TUPLE  (VTrVT2,OPNAME) 

BOUND_TO_TUPLES  (type_spec,int, array  .create) 

IN 


< I,  :VT,  ;E >  {OPNAME^) }  <  E;empty  [VT,]  :VT2-.VT,  > 


array_aeleet: 

This  operation  accepts  and  consumes  two  input  tokens.  The  first  input  token  is  of 
type  array  and  the  second  is  of  type  integer.  Input  token  two  serves  as  the  index  of 
input  token  one.  The  operation  selects  the  element  of  the  array  at  the  index  and  pro¬ 
duces  that  value. 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (int, any, array _select) 

IN 

<Ii:VT1-*VT2iI2:VT1;E>{OPNAME(I1,I2)}<E,E;I,(I2):VT2> 


array_replaee: 

This  operation  accepts  and  consumes  three  input  tokens.  The  first  input  token  is  of 
type  array,  the  second  is  of  type  integer,  and  the  third  has  the  same  type  as  the  ele¬ 
ments  of  the  array.  Input  token  two  serves  as  the  index  of  input  token  one.  Input  to¬ 
ken  two  is  the  value  which  is  to  replace  the  value  at  the  index  of  the  array.  The 
operation  produces  an  array  with  identical  elements  to  input  token  one  except  that  the 
element  at  the  index  is  replaced  by  the  token  on  input  arc  three.  The  notation  M[x/v] 
reads  “M  with  x  for  v.” 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (int, any_type, array _replace) 

IN 


<l1:VT,-.VT2,I2:VTl,Is:VT2;E>{OPNAME(I„l2)I3)}<E,E,E;Ij|yi1(I2)|:VT)-.VT2> 


array_sizc: 

This  operation  accepts  and  consumes  one  input  token  which  is  of  type  array  and  pro¬ 
duces  a  single  output  token  of  type  integer  which  is  the  size  of  the  array. 

FOR.TUPLE  (VTj.VTj.OPNAME) 

BOUND_TO_TUPLES  (int,any,array_size) 

IN 


<I,:VT|— ►VT2;E>  (OPNAME(I[)}  <E;01:VTl  > 
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arrayjow: 

This  operation  accepts  and  consumes  one  input  token  which  is  of  type  array  and  pro¬ 
duces  a  single  output  token  of  type  integer  which  is  the  lower  bound  of  the  array. 

FOR.TUPLE  (VT1(VT2IOPNAME) 

BOUND  TO  TUPLES  (int, any, array  low) 

IN 

<I,:VT,-VT2;E>  {OPNAME(I,)}  <E;01:VT1  > 


array_high: 

This  operation  accepts  and  consumes  one  input  token  which  is  of  type  array  and  pro¬ 
duces  a  single  output  token  of  type  integer  which  is  the  upper  bound  of  the  array. 

FOR.TUPLE  (VTi;VT2,OPNAME) 

BOUND_TO_TUPLES  (int, any, array  high) 

IN 

<I,:VT1— ►VT2;E>  (OPNAME(I,)}  <E;0,:VTi  > 


array_set_bounds: 

This  operation  accepts  and  consumes  three  input  tokens.  The  first  input  token  is  of 
type  array,  the  second  and  third  are  type  integer.  The  operation  produces  an  array 
which  identical  to  the  first  input  token  except  that  the  high  index  has  the  value  of  in¬ 
put  token  two  and  the  low  index  has  the  value  of  input  token  three. 

FOR_TUPLE  (VT^VTj.OPNAME) 

BOUND_TO_TUPLES  (int, any, array _set  bounds) 

IN 

<Ii:VT,— VT2,I2:VT„I3:VT1;E>{0PNAME(II,I2,l3)}<E,E,E;01:VT1— VT2>  A 

lower(0|)=l2  A  upper(0!)=I3 


array_coneatenate: 

This  operation  accepts  and  consumes  two  input  tokens  of  type  array  and  produces  a 
single  output  token  of  type  array.  The  array  produces  has  a  size  equivalent  to  the 
sum  of  the  sizes  of  the  input  arrays,  a  low  index  equal  to  input  token  one’s  index,  and 
a  high  index  equal  to  input  token  two’s  high  index.  Input  token  two  is  concatenated 
with  input  token  one  to  form  the  new  array. 

FOR_TUPLE  (VTpVTj.OPNAME) 

BOUND_TO_TUPLES  (int, any, array  concatenate) 

IN 


<  IpVT.-VTj.IjiVT.-VT^E  >  {OPNAME(I,  ,I2)}  <  E,E;0,  :VT,-VT2  > 


rccord_create : 

This  operation  accepts  and  consumes  one  input  token  which  is  the  type  specification 
for  the  record  to  be  created  and  produces  an  record  of  the  indicated  type. 

FORJTUPLE  (VT,,VT2,OPNAME) 

BOUND_TO_TUPLES  (type_spec,any, record  create) 

IN 

<I1:VT1;E>{OPNAME{Il)}<E;Record[VT1]:FN1-VT2X  X  FN„-VT2> 


record_»elect: 

This  operation  accepts  and  consumes  two  input  tokens.  The  first  input  token  is  of 
type  record  and  the  second  is  a  field  of  the  record.  The  operation  produces  the  value 
of  the  named  field. 

FOR_TUPLE  (VTpVTj.OPNAME) 

BOUND_TO_TUPLES  (field, any  .record  select) 

IN 


FNj=I2  A  <rl:FN1-VT2X 


XFNb-VT2,I2:VT1;E>{OPNAME(I1>I2))<E,E;I1.I2:VT2> 


record_rcplace\ 

This  operation  accepts  and  consumes  three  input  tokens.  The  first  input  token  is  of 
type  record,  the  second  is  a  field  of  the  record,  and  the  third  is  a  value  which  is  to  re¬ 
place  the  current  value  of  the  named  field.  The  operation  produces  a  record  similar  to 
the  record  on  input  arc  one  except  that  the  value  of  the  named  field  is  replaced  by  the 
token  on  input  arc  three. 

FORJTUPLE  (VTj  ,VT2,OPNAME) 

BOUND_TO_TUPLES  (field, any ,record_replace) 

IN 

FNi=I»(l<i<n)  A  <I,:FNl-VT2X  •••  X  FNn-VT2,I2:VT„I3:VT2;E> 
{OPNAME(l1,I2,l3)}<E,E,E;Il|I2:Ij]:FN1->VT2  X  •  X  FND-VT2>  A  (*l<i<n) 


union_ereate : 

This  operation  accepts  and  consumes  one  input  token  which  is  the  type  specification 
for  the  union  to  be  created  and  produces  a  union  of  the  indicated  type. 

FORJTUPLE  (VT1,VT2,OPNAME) 

BOUND JTOJTUPLES  (type_spec,any,union_create) 

IN 


<I1:VT1;E>{OPNAME(I1))<E;01:Ti-VT2>  A  (l<i<n) 


union_tag_teat: 

This  operation  accepts  and  consumes  two  input  tokens  and  produces  a  single  output 
token  of  type  boolean.  The  result  of  this  operation  is  true  if  the  union  on  input  arc 
one  was  created  with  a  tag  of  input  arc  two.  Otherwise,  j.  value  of  False  is  produced. 

FOR_TUPLE  (VTj.VT^VTg.OPNAME) 

BOUND_TO_TUPLES  (tag, any, boolean, union_tag_test) 

IN 


(tagnameOLlg^P)  A  <I1:T1-.VT2)I4:VTi;E>{OPNAME(I„y}<E,E;P:VTs> 


rcal_to_int: 

This  operation  accepts  and  consumes  a  single  input  token  of  type  real  and  produces  a 
single  output  token  of  type  integer.  The  input  token  is  converted  to  an  integer  using 
machine  dependent  conversion  rules. 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (real, int, real  to_int) 

IN 

<I,:VT1;E>  {OPNAME(I,)}<E;01:VT2> 


char_to_int: 

This  operation  accepts  and  consumes  a  single  input  token  of  type  character  and  pro¬ 
duces  a  single  output  token  of  type  integer.  The  input  token  is  converted  to  an  in¬ 
teger  using  machine  dependent  conversion  rules. 

FOR_TUPLE  ( VT, , VTj.OPNAME) 

BOUND_TO_TUPLES  (char, int, char_to_int) 

IN 

<I1:VT1;E>{OPNAME(Il)}<E;01:VT2> 


float:  This  operation  accepts  and  consumes  a  single  input  token  of  type  integer  and  produces 
a  single  output  token  of  type  real.  The  input  token  is  converted  to  a  real  number  us¬ 
ing  machine  dependent  conversion  rules. 

FOR_TUPLE  (VTrVT2,OPNAME) 

BOUND_TO_TUPLES  (int, real, float) 

IN 


<I1:VTl;E>{OPNAME(I1)}<E;01:VT2> 
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int_to_ekar. 

This  operation  accepts  and  consumes  a  single  input  token  of  type  integer  and  produces 
a  single  output  token  of  type  character.  The  input  token  is  converted  to  a  character 
using  machine  dependent  conversion  rules. 

FOR_TUPLE  (VTltVT2,OPNAME) 

BOUND_TO  TUPLES  (int,char,int_to_char) 

IN 


<Il:VT1;E>{OPNAME(I1)}<E;01:VT2> 


floor :  This  operation  accepts  and  consumes  a  single  input  token  of  type  real  and  produces  a 
single  output  token  of  type  integer.  The  input  token  is  converted  to  an  integer  using 
machine  dependent  conversion  rules. 

FOR_TUPLE  (VT^VTj.OPNAME) 

BOUND_TO  TUPLES  ( real, int, floor) 

IN 

<I1:VT,;E>{OPNAME(I1)}<E;01:VT2> 


trunc:  This  operation  accepts  and  consumes  a  single  input  token  of  type  real  and  produces  a 
single  output  token  of  type  integer.  The  input  token  is  converted  to  an  integer  using 
machine  dependent  conversion  rules. 


FOR_TUPLE  (VTjjVTj.OPNAME) 

BOUND_TO_TUPLES  (real, int, trunc) 

IN 

<I1:VT1;E>{OPNAME(I1)}<E;01:VT2> 


first:  This  operation  accepts  and  consumes  a  stream  of  input  tokens  and  produces  a  single 
stream  of  output  tokens  each  of  which  have  the  value  of  the  first  token  in  the  input 
stream.  The  notation  I#.i  refers  to  the  ith  element  of  the  stream  on  input  arc  #.  For 
example,  I  .1  refers  to  the  first  element  of  input  stream  number  one. 


FOR.TUPLE  (VT,OPNAME) 
BOUND_TO_TUPLES  (any, first) 

IN 


<Il.i:VT;E>  {OPNAME(Ij)}  <E;I,.l:VT> 


rest:  This  operation  accepts  and  consumes  a  stream  of  input  tokens  and  produces  a  single 
stream  of  output  tokens.  At  each  step  of  the  execution,  the  output  token  produced  is 
the  next  token  to  arrive  on  the  input  arc  (i.e.,  the  next  token  in  the  input  stream). 
The  stream  produced  by  the  filter  is  the  input  stream  less  the  first  token. 

FOR.TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (any, rest) 

IN 


<I1.i:VT;E>{OPNAME(I1)}<E;I,.i+l:VT> 


whenever: 

This  operation  accepts  and  consumes  two  streams  of  input  tokens  and  produces  a  sin¬ 
gle  stream  of  output  tokens.  For  each  token  set,  if  the  value  of  the  token  on  the 
second  input  arc  is  True,  then  the  token  on  the  first  input  arc  (data  token)  is  placed 
on  the  output  arc.  Otherwise,  the  filter  discards  the  data  token.  The  filter  produces  a 
stream  of  all  values  of  the  data  stream  whose  corresponding  control  stream  value  was 
true.  Two  axioms  are  used  to  define  the  semantics  of  this  operation. 

FOR_TUPLE  (VTrVT2,OPNAME) 

BOUND_TO_TUPLES  (any, boolean  .whenever) 

IN 

<Ii:VT1,True:VT2;E>{OPNAME(I1.i,I2.i)}<E.E;I1.iVT1>, 


<I1:VT„False:VT2;E>{OPNAME(I1.i,I2.i)}<E,E;E> 
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advance_upon: 

This  operation  accepts  and  consumes  two  streams  of  input  tokens  and  produces  a  sin¬ 
gle  stream  of  output  tokens.  This  filter  places  the  first  token  in  input  stream  one  on 
j  the  output  arc.  Then  for  each  successive  token  set,  if  the  value  of  the  token  on  the 

i  second  input  arc  is  True,  then  the  token  on  the  first  input  arc  (data  token)  is  placed 

■  on  the  output  arc.  If  the  value  is  False,  the  value  that  was  last  placed  on  the  output 

arc  is  placed  on  the  output  arc  again  and  the  token  on  input  arc  one  is  left  on  the  arc. 
The  filter  produces  a  stream  of  values  of  the  data  stream,  some  of  which  are  repeated. 
Three  axioms  are  used  to  define  the  semantics  of  the  operation. 

•  FOR.TUPLE  (VTj.VT^OPNAME) 

>  BOUND_TO  TUPLES  (any, boolean, advance_upon) 

1  IN 

|  <I1.l:VT1,I2.I:VT2;E>{OPNAME(I1.l,I2.l)}<E,E;I!.l:VT1>, 


<I1:VT1,True:VT2;E>{OPNAME(II.1,I2.i)}<E,E;I1.i:VT1>, 


<Il:VT1,False:VT2;E>{0PNAME(I1.i,I2.i)}<I1.i,E;01.i-l> 


concatenate: 

This  operation  accepts  and  consumes  two  streams  of  input  tokens  and  produces  a  sin¬ 
gle  stream  of  output  tokens.  The  resultant  stream  is  formed  by  concatenating  the 
second  input  stream  to  the  first  input  stream. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (any .concatenate) 

IN 

<  I,:VT,I2:VT;E  >  (OPNAMEJI,  ,I2)}  <  E,E;0,  :VT  > 

i 

i 

i 

i 

|  is_current : 

The  is_current  accepts  and  consumes  a  single  stream  of  input  tokens  and  produces  a 
single  stream  of  output  tokens.  The  declaration  is  used  to  freeze  certain  the  value  of 
an  identifier.  The  declaration  allows  programmers  to  write  programs  with  nested 
iteration. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TLrPLES  (any,is_current) 

IN 

<I,.i:VT;E>  {OPNAME(I,.i)}  <E;I1.i:VT> 


merge: This  operation  has  three  input  arcs  and  a  single  output  arc.  Input  arc  one  serves  as 
the  control  input  for  the  operation.  Input  arc  one  carries  tokens  of  type  boolean  and 
input  arcs  two  and  three  carry  tokens  of  any  type.  The  operations  consumes  the  input 
tokens  on  the  control  arc  and  the  input  data  arc  pointed  to  by  the  control  token.  A 
copy  of  the  data  token  on  the  specified  input  data  arc  is  is  placed  on  the  output  arc. 
Two  axioms  are  used  to  define  his  operation. 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (bool, any, merge) 

IN 


<True:VT1,I2:VT2,E;E>{OPNAME(I1,I2,l3)}<E,E,E;I2.VT2>, 


<False:VT1,E,I3:VT3;E>  {OPNAME(I,,I2,I3)}  <E,E,E;I3:VT2> 


outbound_awiteh: 

This  operation  has  two  input  arcs  and  two  output  arcs.  Input  arc  one  serves  as  the 
control  input  for  the  op'  ration  and  input  arc  two  serves  as  the  data  input.  Input  arc 
one  carries  tokens  of  type  boolean  and  input  arc  two  carries  tokens  of  any  type.  The 
operations  consumes  the  input  tokens  and  the  value  of  the  control  token  is  used  to 
select  the  output  arc  on  which  a  copy  of  the  data  token  will  be  placed.  If  the  value  of 
the  control  token  is  True,  then  the  data  token  is  placed  on  output  arc  one.  Otherwise, 
the  data  token  is  placed  on  output  arc  two.  Two  axioms  are  used  to  define  this  opera¬ 
tion. 

FOR_TUPLE  ( VT( , VT2,OPNAME) 

BOUND_TO_TUPLES  (bool, any  .outbound  switch) 

IN 


<True:VT„I2:VT2;E,E>  {OPNAME(I,,I2)}  <E,E;I2:VT2,E> , 


<False:VT1,I2:VT2;E,E>{OPNAME(I1,I2))<E,E;E,I2:VT2> 


identity: 

This  operation  accepts  and  consumes  one  input  token  of  any  type  and  produces  an 
output  token  of  any  type  which  has  the  value  of  the  input  token.  Thus,  a  copy  of  the 
input  token  is  placed  on  the  output  arc. 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (any, identity) 

IN 


<  I1:VT;E>  (OPNAME(I,)}  <E;I,:VT> 


routc_tokcna : 

This  operation  accepts  and  consumes  two  input  tokens.  The  token  on  input  arc  one  is 
the  control  token  and  is  of  type  integer.  The  token  on  input  arc  two  is  of  any  type. 
The  operation  places  the  data  token  on  the  output  arc  specified  by  the  control  token. 

FOR.TUPLE  (VT,  ,VT2,OPNAME) 

BOUND_TO_TUPLES  (any,int,route_tokens) 

IN 

(l<Ij<n)  A  <I,:VT1,I2:VT2;E1,  ■■■  ,EB>{OPNAME(I„I2)}<E,E;E1,  ,E^_,,IltE^+|,  •••  ,En> 


fvnnel_tokens : 

This  operation  accepts  and  consumes  N  input  tokens.  The  token  on  input  arc  one  is 
the  control  token  and  is  of  type  integer.  The  tokens  on  input  arc  two  to  N  are  of  any 
type.  The  operation  places  the  data  token  on  the  output  arc  specified  by  the  control 
token.  The  operation  consumes  the  control  token  and  the  data  token  from  the  input 
arc  specified  by  the  control  token.  The  data  token  is  placed  on  the  output  arc. 

FOR_TUPLE  (VT,,VT2>OPNAME) 

BOUND_TO_TUPLES  (any,int,funnel_tokens) 

IN 


<I1:VT2,...E,r„  I^VT,  .E,i+1....;E>{OPNAME(I1, 


.!»)}<£,  •  •  • 


apply.  This  operation  accepts  and  consumes  two  input  tokens  and  produces  N  output  tokens. 
The  token  on  input  arc  one  is  a  procedure  definition  which  is  to  be  applied  to  the  argu¬ 
ment  list  on  input  arc  two.  The  operation  is  used  to  make  a  run-time  binding  of  the 
procedure  definition  to  the  argument  list.  The  operation  produces  N  output  tokens 
which  are  the  results  of  applying  the  procedure  definition  to  the  argument  list. 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (function, any, apply) 

IN 


<Ij:VT1,l2:VT2>...ID:VT2;E1,...,Em>{0PNAME(II,...,ln)}<E,E;01:VT2 . Om:VT2> 
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input  This  operation  is  used  to  receive  input  from  the  programming  environment.  It  accepts 
input  from  a  programmer’s  terminal  and  produces  a  token  which  has  the  value  that 
was  input. 

FOR_TUPLE  (VT, OPNAME) 

BOUND  TO_TUPLES  (any, input) 

IN 


<  ;E  >  {OPNAME}  <  jO,  :VT> 


output'. 

This  operation  is  used  to  output  values  to  the  programming  environment.  The  opera¬ 
tion  accepts  and  consumes  a  single  token  of  any  type.  It  then  outputs  the  token  to 
the  programming  environment. 

FOR_TUPLE  (VT, OPNAME) 

BOUND_TO_TUPLES  (any, output) 

IN 

<VT;>{OPNAME(I1)}<E;> 


constant: 

This  operation  accepts  and  consumes  two  input  tokens  and  produces  a  single  output 
token.  Input  token  one  is  used  to  trigger  the  firing  of  the  node.  Input  arc  two  carries 
the  value  of  the  constant  to  be  produced  by  the  node.  The  output  token  has  the  same 
type  and  value  as  the  data  constant  token. 

FOR_TUPLE  (VT, OPNAME) 

BOUND_TO_TUPLES  (any, constant) 

IN 


legal_constant(I2)  A  <I1:VT,I2:VT;E>  (OPNAME(I1,I2)} <E,I2:VT;I2:VT> 


fork-.  This  operation  accepts  and  consumes  a  single  input  token  and  produces  n  copies  of  the 
input  token  on  N  output  arcs.  Tokens  of  any  type  are  accepted  and  any  number  of 
output  arcs  can  be  specified. 

FOR_TUPLE  (VT, OPNAME) 

BOUND_TO_TUPLES  (any, fork) 

IN 


<II:VT;E1...E0>{OPNAME(I,)}<E;I1:VT . I,:VT> 
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if-then-elae: 

The  if-then-else  construct  accepts  one  control  input  and  n  data  inputs.  The  data  in¬ 
puts  are  sent  to  either  the  then  or  the  else  expression  depending  upon  the  value  of  the 
control  input.  If  the  control  input  is  true,  then  the  data  inputs  are  sent  to  the  then 
expression.  Otherwise,  the  data  inputs  are  sent  to  the  else  expression.  Once  an  ex¬ 
pression  receives  the  data  inputs,  the  expression  executes  and  produces  m  output 
values  which  are  the  values  produced  by  the  construct. 

FORJEACH(VT) 

BO  UND_TO_ONE_OF(int,  real,  bool,  char,  array , record,  union,  function) 

IN 

<I,:bool,  •  •  •  .IjcVT ln:VT;Et,  ■  ■  •  ,Em>  A  I0  =  true  (S1}<E„  ■  ,En;0,:VT Om:VT>, 

<l,:bool,  •  •  •  ,Ij:VT In:VT ;E,,  •  ■  •  ,Em>  A  I0  =  false  {S2}<E„  ■  •  •  .E^O^VT Om:VT>, 

<Il:bool,I8:VT . ln;E„  •  •  •  ,Em>{lf  lo  then  S,  else  S2}<E„  •  •  •  ,E„;0,:VT,  •  •  •  ,Om:VT> 


begin:  The  begin  construct  accepts  n  input  values  and  produces  m  output  values.  The  con¬ 
struct  uses  several  sub-expressions  (Sj)  which  receive  input  values  from  the  input 
values  received  by  the  construct  and/or  the  values  produced  by  other  sub-expressions. 
The  values  produced  by  each  sub-expression  can  be  used  by  the  other  sub-expressions 
or  can  be  values  produced  by  the  construct. 

FOR.EACH(VT) 

BOUND_TO_ONE_OF(int, real, bool, char, array, record, union, function) 

IN 

<At:VT . Ap:VT;El,...,Em>  A  Ap  €  {{Ij . I„}  U  {Ok}},l<  n  an  ki 

{Si}<E1,...,Ep;Oi:VT>  A  l<<n 

<I1:VT,...,In:VT;El . Em>{begln  Sl;S2;..~Sk  cnd}<E, . En;0,:VT . Om>  A  0,0;  ,l<l<n 


case:  The  case  construct  accepts  n  input  data  values  and  one  value  of  type  union.  The 
union-typed  value  determines  which  sub-expression  of  the  construct  will  be  executed 
(i.e.,  the  expression  whose  tag  matches  the  tag  of  the  union-typed  value).  The  selected 
expression  receives  all  input  values  and  the  constituent  value  of  the  union,  executes 
and  produces  m  output  values.  These  values  are  the  output  values  produced  by  the 
construct. 

FORJEACH(VT) 

BOUND_TO  ONE_OF(int, real, bool, char, array, record, union, function) 

IN 

<I1:VT,...In:VT;E) . Em>{Sk+l}<E,„.  En;0,:VT . Om:VT>. 

_ Is  Tj  x  A  <x  [  Tl:VT,l1:VT....I„:VT;El . Em>  <E1,...E„;0,:VT . Om:VT> _ 

<I1:VT,In:VT;E,,...,Em>{case  p:  =  x:union  of  T  1:S , ;  ,.;Tk:Sn;default:Sk+lend} <E,,... En;0,:VT . Om:VT > 


forall_cval: 

The  forall_eval  construct  accepts  n  input  data  values  and  the  lower  and  upper  bounds 
of  the  range  of  the  construct.  The  construct  creates  upper-lower+1  unique  instantia¬ 
tions  of  the  body  of  the  construct  (S.)  which  are  executed  concurrently.  Each  instan¬ 
tiation  produces  a  single  value.  The  construct  produces  a  single  value  which  is  the 
result  of  applying  an  operation  (op_name)  on  ail  the  values  produced  by  the  unique  in¬ 
stantiations  of  the  body. 

FOR_EACH(VT) 

BOUND_TO_ONE_OF(int,  real,  bool, char, array, record, union, function) 

IN 

<i:int,I,:VT . In:VT;E1>{S1}<E, . E„;0,:VT>  A  (L<i<U). 

_ F  €  (plus, mult, anchor, min, max} _ 

<lnl:VT,....Inn:VT;E>{rorall  i  In  |L,U|  do  S,  eval:F}< El,...,En;F(01,F(02,...,F(0lHj,0u^+l)...))> 


forall_constrvct: 

The  forall_construct  construct  acts  in  the  same  manner  as  the  foratt_eval  construct  ex¬ 
cept  that  an  array  is  created.  The  elements  of  the  array  are  the  values  produced  by 
the  unique  instantiations  of  the  body. 

FORJEACH(VT) 

BOUND_TO_ONE_OF(int, real, bool, char, array, record, union, function) 

IN 

_ <i:int,Ii:VT . ln:VT;E1>{S1}<El . En;Ot:VT>  A  (L<i<U), _ 

<In1:VT,...,Inn:VT;E>{forall  i  In  [L,U|  do  S|  con»truct}<E, . E„;0:int-*VT> 


for_iter: 

The  for_iter  construct  accepts  n  input  values  which  are  the  initial  values  of  the  loop 
variables  of  the  construct.  On  each  iteration  of  the  loop,  an  if-then-else  construct  is 
used  to  test  for  loop  termination.  If  the  loop  is  to  terminate,  an  expression  (Sj  is 
evaluated.  The  results  of  the  expression  are  the  results  produced  by  the  construct.  If 
the  loop  does  not  terminate,  another  expression  (S„)  is  evaluated.  In  this  expression, 
some  updating  of  the  variables  of  the  loop  is  performed  (i.e. ,  the  next  iteration  of  the 
loop  is  performed). 

FOR_EACH(VT) 

BOUND_TO  ONE_OF(int,  real,  bool, char, array  .record, union, function) 

IN 

<In,:V'T1 . Ink:VTk;E, . Ej>  A  (l<k,j<n){lnltlollze}<E1,  •  ,Ek;0,:VT,.  ,Oj:VTj> 

~B  A  <In,:VT„  ,Inn:VT„;E„  •  ■  •  ,Em>  {S,}<In1:VT„  ,InB:VTn;E,.  ,Em> 

_ B  A  <Int:VT|,  ■  ■  ■  .IryVTniEt,  ■  •  ■  ,Em>  A  (l<m<n){So)<E1,  ■  .E^O'A'T',  •  ■  .Um:VTm> _ 

<-  ln,:VT |,  •  •  .InQ:VTn;E|,....Em>  {for  initialize  do  If  B  then  S,  else  S.,  end}<E,.  •  •  .En:0,:VT,.  ,Om:\ ' 


APPENDIX  E 


DATA  STRUCTURES  OF  PDL 


This  appendix  gives  the  data  structures  used  to  completely  describe  all  operations  and  pro¬ 
gram  constructs  of  PDL.  The  names  component  gives  the  names  of  the  language  constructs 
described  by  the  data  structure.  The  semantics  component  gives  the  semantical  description  of  the 
language  construct.  The  graphics  component  gives  a  reference  to  an  executable  procedure  that 
draws  the  icons  representing  the  language  construct.  The  textual  component  gives  a  reference  into 
the  BNF  grammar  to  the  grammar  rule  which  describes  the  language  construct.  (The  actual  syn¬ 
tax  used  within  a  program  may  also  be  given  in  the  textual  component). 


add_n ode 

{ 

names:  int_add,  real_add; 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_add),  (real,real_add) 

IN 

<I,:VT,I2:VT;E>{OPNAME(I1.Io)}<E.E;I1  +  I2:VT> 

graphics:  draw_add_node; 

textual:  +{I  ,I„);  (simple-expression) 

} 


subtract_node 

{ 

names:  int_subtract,  real_subtract; 
semantics: 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TLiPLES  (int,int_subtract),  (real,real_subtract) 

IN 

<I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;I1-I2:VT> 

graphics:  draw_subtract_node; 
textual:  -(I,,I2);  (simple-expression) 

} 


multiply  _node 

{ 

names:  int_multiply,  real_multiply; 
semantics: 

FOR_TUPLE  (VT,OPNA\IE) 

BOUND_TO_TUPLES  (int,int_multiply),  (real,real_multiply) 

IN 

<  I,  :VT,I2:VT;E  >  {OPNAME(I,  ,I2)}  < E,E;I,  X  I2:VT  > 

graphics:  draw_multiply_node; 
textual:  *(I1(I2);  (term) 

} 


divide_node 

{ 

names:  int_divide,  real_divide; 
semantics: 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int.int.divide),  (real,real_divide) 

IN 

<Ii:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;I1-t-I2:VT> 

graphics:  draw_divide_node: 
textual:  /(I,,lJ;  (term) 

} 
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exponentiation  node 

{ 

names:  int_exp,  real_exp; 
semantics: 

FOR.TUPLE  (VT,OPNAME) 

BOUND_TO  TUPLES  (int,int_exp),  (real,real_exp) 

IN 

<I1:VT,I2:VT;E>  {OPNAME(I„I2)}  <E,E;I,l2:VT> 

graphics:  draw_exp_node; 

textual:  exp(I1,I2);  (prefix-operation) 

} 


modulus_node 

{ 

names:  int_mod; 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_modulus) 

IN 

<I,:VT,I2:VT;E>{OPNAME(I„I2)}<E>E;Ii  mod  I2:VT> 

graphics:  draw_mod_node; 
textual:  mod(I1,I2);  (term) 

} 


negation_node 

{ 

names:  int_negation,  real_negation; 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_negation),  (real,real_negation) 
IN 

<I1:VT;E>{OPNAME(I,)}<E;0  -  I,:VT> 

graphics:  draw_negation_node; 
textual:  -(It);  (factor) 

} 


absolute  value_node 

{ 

names:  int_absolute,  real_absolute; 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND  TO_TUPLES  (int,int_absolute),  (real,real_absolute) 
IN 

<I,:VT;E>{OPNAME{I1)}<E;|  I,|:VT> 

graphics:  draw_abs_node; 
textual:  abs(I,);  (prefix-operation) 

} 


maximum_node 

{ 

names:  int_max,  real_max; 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_max),  (real,real_max) 

IN 

(Ii  >  Ij,l<id<2)A  <Il:VT,I2:VT;E>{OPNAME(I1,I2)}<EIE;Ii:VT> 

graphics:  draw_max_node; 

textual:  max(I,,I2);  (prefix-operation) 

} 


minimum_node 

{ 

names:  int_min,  real_min; 
semantics: 

FOR__TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_min),  (real,real_min) 

IN 

(Ii  <  Ij.l<iJ<2)A  <It:VT,I2:VT;E>{OPNAME(Il,I2)}<E,E:Ii:VT> 

graphics:  draw_min_node; 

textual:  min(I,,I2);  (prefix-operation) 
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equal  node 

{ 

names:  int_equal,  real_equal,  bool_equal,  char_equal; 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_equal),  (real,real_equal), 

(bool,bool_equal),  (char,char_equal) 

IN 

(I,  =l2)«pA  <I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E1E;P:Boo1> 

graphics:  draw_equal_node; 
textual:  =(I.,L);  (expression) 

} 


not_equal_node 

{ 

names:  int_not_equal,  real_not_equal,  bool_not_equal,  char_not_equal; 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_not_equal),  (real,real_not_equal), 

(bool,bool_not  equal),  (char, char  not  equal) 

IN 

(I,  jk  I2)«=*p  a  <I1:VT,I2:VT;E> {OPNAME(I],I2)} <E,E;P:Bool> 

graphics:  draw_not_equal_node; 
textual:  !=(I1,I2);  (expression) 

} 


greater_than_node 

{ 

names:  int_greater_than,  real_greater_than,  bool_greater_than,  char_greater_than; 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_greater_than),  (real,real_greater_than), 
(bool,greater_than),  (char,char_greater_than) 

IN 

(I,  >  y«PA  <I1:VT,I2:VT;E>{OPNAME(I1,I2)}<E,E;P:Bool> 

graphics:  draw_greater_than_node; 
textual:  >(I  ,I0);  (expression) 

} 
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less_than_node 

{ 

names:  int_less_than,  real_less_than,  bool_less_than,  char_less_than; 
semantics: 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (int,int_less_than),  (real,real_less_than), 

(bool,bool_less_than),  (char,char_less_than) 

IN 

(I,  <  I2)«Pa  <I1:VT,I2:VT;E>  {OPNAME(I1,I2)}<E,E;P:Bool> 

graphics:  draw_less_than_node; 
textual:  <(I,,I2);  (expression) 

} 


greater  than_equal_node 

{ 

names:  int_greater_equal_than,  real_greater_equal_than, 

bool_greater_equal_than,  char_greater_equal_than; 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_greater_equal),  (real,real_greater_equal), 

(bool,bool_greater_equal),  (char,char_greater_equal) 
IN 

(Ii  >  Ia)«=»P  A  <Ii:VT,I2:VT;E>{OPNAME(I1>I2)}<E,E;P:Bool> 

graphics:  draw_greater_than_equal_node; 
textual:  >  =(It  ,I2);  (expression) 

} 


less_than_equal_node 

{ 

names:  int_less_equal_than,  real_less_equal_than, 

bool_less_equal_than,  char_less_equal_than; 

semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND_TO_TUPLES  (int,int_less_equal),  (real,real_less_equal), 
(bool,bool_not  equal),  (char,char_not_equal) 

IN 

(I,  <  I2)«=>P  A  <I,:VT,I2:VT;E>  {OPNAME(I1,I2)}<E,E;P:Bool  > 

graphics:  draw_less_than_equal_node; 
textual:  <=(I1,I2);  (expression) 

} 
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and_node 

{ 

names:  bool_and 
semantics: 

FOR.TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (bool,bool_and) 

IN 

(I,  a  I2)<=»P  A  <I1:VT,I2:VT;E>{OPNAME(I1)I2)}<E,E;P:Bool> 

graphics:  draw_and_node; 
textual:  &&(Ij,I2);  (term) 

} 


or_node 

{ 

names:  bool_or 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO_TUPLES  (bool,bool_or) 
IN 


(It  |  I2)<=>P  A  <I1:VT.I2:VT;E>{OPNAME(II,I2)}<E,E;P:Bool> 

graphics:  draw_or_node; 

textual:  |(I1,I2);  (simple-expression) 

} 


not_node 

{ 

names:  bool_not 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO_TUPLES  (bool, bool  not) 
IN 


<I1:VT;E>(OPNAME(I,)}<E;'  I,:VT> 

graphics:  draw_not_node; 
textual:  !(Ij);  (factor) 

} 
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array  _create_node 

{ 

names:  array _create 
semantics: 

FOR.TUPLE  (VTj.VT^OPNAME) 

BOUND  TO_TUPLES  (type_spec ,int, array _create) 

IN 

<I1:VTl;E>  {OPNAME(I1)}  <E;empty[VT1j:VT2-*VT1  > 
graphics:  draw_array_create_node; 

textual:  empty  [type-spec];  (constant  or  array-generator) 

} 


array  _select_node 

{ 

names:  array _select 
semantics: 

FOR_TUPLE  (VT,,VT2,OPNAME) 

BOUND_TO_TUPLES  ( int ,  any ,  array jseiec  t) 

IN 

<  I,  :VT,-VT2lI2:  VT,;E  >  (OPNAME(I,  ,I2)}  <  E,E;I,(I2):VT2  > 

graphics:  draw_array_select_node; 
textual:  (array-ref) 

> 


array_re  p  1  ac  e_node 

{ 

names:  array _replace 
semantics: 

FOR_TUPLE  (VT^VT^OPNAME) 

BOUND_TO_TUPLES  (int,any_type,array_replace) 

IN 

<l1:VT1-VT2,I2:VT1.Is:VT2;E>{OPNAME(Il,I2,Is)}<E,E,E;I1Hs/'I1(Is)|:VT1-VT2> 

graphics:  draw_array_replace_node; 
textual:  (array-generator) 

} 


118 


array  size_node 

{ 

names:  array  _size 
semantics: 

FOR_TUPLE  (VTj , VT2,OPNAME) 

BOUND  TO  TUPLES  (int, any, array  size) 

IN 

<Il:VT1— *VT2;E>  {OPNAME(I1)}<E;01:VTI  > 

graphics:  draw_array_size_node; 
textual:  array_size(I1)  (prefix-operation) 

} 


array_low_node 

{ 

names:  array _low 
semantics: 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (int, any, array  low) 

IN 

<Ii:VT1-»VT2;E>{OPNAME(I1)}<E;01:VT1> 

graphics:  draw_array_low_node; 
textual:  array^ow^);  (prefix-operation) 

} 


array  _high_node 

{ 

names:  array_high 
semantics: 

FORJTUPLE  (VT,,VT2,OPNAME) 

BOUND_TO_TUPLES  (int, any, array  high) 

IN 

<I1:VT1— *VT2;E>  (OPNAME(I,)}  <E,Of  :VT,  > 

graphics:  draw_array_high_node; 
textual:  array_high(Ij);  (prefix-operation) 

} 
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array _set  bounds  node 

{ 

names:  array _set_bounds 

ep  m  ft  n  1 1  ■ 

FOR_TUPLE  (VTj.VTj.OPNAME) 

BOUND_TO  TUPLES  (int, any, array  set  bounds) 

IN 

<I1:VT1-VT2,I2:VT1,I3:VT1;E>{0PNAME(I1,I2,l3)}<E,E,E;01:VT1-.VT2>  A 

lower(Oi)=I2  A  upper(0!)=I3 

graphics:  draw_array_set_bounds_node ; 
textual:  set_bounds(I1,I2,I3);  (prefix-operation) 

} 


array_concatenate  node 

{ 

names:  array_concatenate 
semantics: 

FOR_TUPLE  (VTj.VTj.OPNAME) 
BOUND_TO_TUPLES  (int,any,array_concatenate) 
IN 


<Ii:VT[— ►VT2,I2:VT1— ♦VT2;E>{OPNAME(I1,I2)}  <E,E;01:VT1— »VT2> 

graphics:  draw_array_concatenate_node; 
textual:  array  _cat(Ij,I2);  (prefix-operation) 

} 


record  create_node 

{ 

names:  record_create 
semantics: 

FOR_TUPLE  (VTpVT^OPNAME) 
BOUND_TO_TUPLES  (type  spec, any, record_create) 
IN 


<Ii:VT1;E>{OPNAME(I1)}<E;Record[VT,]:FN1-VT2X  •••  X  FNn-VT2> 

graphics:  draw_record_create_node; 
textual:  (record-generator); 

} 
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record_select_node 

{ 

names:  record_select 
semantics: 

FOR.TUPLE  (VT^VT^OPNAME) 

BOUND_TO_TUPLES  (field, any ,record_select) 

IN 

FN^LjA  <Ii;FN,-VT2X  •  ■  •  X  FNn-VT2,I2;VT1;E>{OPNAME(I„I2)}<E,E;I1.L2:VT!,> 

graphics:  draw_record_select_node; 
textual:  (record-ref); 

} 


record_replace_node 

{ 

names:  record_select 
semantics: 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO_TUPLES  (field, any ,record_replace) 

IN 

FN,=l2,(l<i<n)  A 

<I,:FN,-VT2X  ■  XFNn-VT2,I2;VTl,IJ:VT2;E>{OPNAME(I1,I2,Is)}<E,E,E;I1|l2:Is|:FN1-VT2X  X  FNB-VT,> 

A{l<i<n) 

graphics :  draw_record_replace_node ; 
textual:  (record-generator); 

} 


union_create_node 

{ 

names:  union_create 
semantics: 

FOR_TUPLE  (VT^VT^OPNAME) 

BOUND_TO_TUPLES  (type_spec,any,union_create) 

IN 

<I1:VTI;E>{OPNAME(I1)}<E;0,:Ti-VT2>  A  (l<i<n) 

graphics:  draw_union_create_node; 
textual:  (union-generator); 

} 
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union_tag_test_node 

{ 

names:  union_tag_test 
semantics: 

FOR_TUPLE  (VTltVT2>VT3,OPNAME) 

BOUND_TO  TUPLES  (tag,any,boolean,union  tag_test) 

IN 

(tagnameOi.Igj^P)  A  <1,:T1-VT2,I2:VT1;E> {OPNAME(I„I2)}<E,EiP:VTs> 

graphics:  draw_union_tag_test_node; 
textual:  (union-test); 

} 


real  to_int  node 

{ 

names:  real_to_int 
semantics: 

FOR.TUPLE  (VT,,VT2IOPNAME) 

BOUND_TO  TUPLES  (real ,int, real  to  int) 

IN 

<  I,  :VT,  ;E>  (OPNAME(I, ) }  <  E;0, :  VT2  > 

graphics:  draw_real_to_int_node; 
textual:  int(Ij);  (prefix-operation) 

} 


char_to_int_node 

{ 

names:  char_to_int 
semantics: 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND_TO  TUPLES  (char, int, char  to_int) 

IN 

< I ,  VTi;E >  {OPN AME(I, )}  < E;0 , :VT2  > 

graphics:  draw_char_to_int_node; 
textual:  int _ c(Ij );  (prefix-operation) 

} 


float_node 

{ 

names:  float 
semantics: 

FOR_TUPLE  (VTl(VT2,OPNAME) 

BOUND  TO  TUPLES  (int, real, float) 

IN 

<I1:VT,;E>{OPNAME(I1)}<E;01:VT2> 

graphics:  draw_float_node; 
textual:  float(Ij);  (prefix-operation) 

} 


int_to_char_node 

{ 

names:  int_to_char 

c  a  m  9ntir5' 

FOR.TUPLE  (VT^VT^OPNAME) 

BOUND_TO_TUPLES  (int, char, int_to_char) 

IN 

<I1:VT,;E>{OPNAME(I1)}<E;01:VT2> 

graphics:  draw_int_to_char_node; 
textual:  charfl,);  (prefix-operation) 

} 


floor_node 

{ 

names:  floor 
semantics: 

FOR_TUPLE  (VT^VTj.OPNAME) 

BOUND_TO_TUPLES  (real, int, floor) 

IN 

<I1:VT1;E>{OPNAME(I1)}<E;0,:VT2> 

graphics:  draw_floor_node; 
textual:  floor(L);  (prefix-operation) 
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trunc_node 

{ 

names:  trunc 
semantics: 

FOR_TUPLE  (VTj.VT^OPNAME) 

BOUND _TO  TUPLES  (real,int,trunc) 

IN 

<  I,  :VT,  ;E  >  {  OPNAME(I, ) }  <  E;0, :  VT2  > 

graphics:  draw_trunc_node; 
textual:  trunc^);  (prefix-operation) 

} 


first_node 

{ 

names:  first 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (any, first) 

IN 

<I1.i:VT;E>{OPNAME(I,)}<E;I1.l:VT> 

graphics:  draw_first_node; 
textual:  first(Ij);  (prefix-operation) 

} 


rest_node 

{ 

names:  rest 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO  TUPLES  (any, rest) 

IN 

<I1.i:VT;E>{OPNAME(I1)}<E;l1.i+l:VT> 

graphics:  draw_rest_node; 
textual:  rest^);  (prefix-operation) 

} 
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whenever_node 

{ 

names:  whenever 
semantics: 

FOR_TUPLE  (VT^VT^OPNAME) 

BOUND_TO  TUPLES  (any,boolean,whenever) 

IN 

<I1:VT1,True:VT2:E>{OPNAME(I1.i,I2.i)}<E,E;I1.iVT1>, 


<  I,  :VT !  ,F  alse:  VTjjE  >  {OPNAME(I,.i,I2.i)}  <E,E;E> 

graphics:  draw_whenever_node; 

textual:  whenever^, I2);  (prefix-operation) 

} 


advanc e_upon_node 

{ 

names:  advance_upon 
semantics: 

FOR_TUPLE  (VT1,VT2,OPNAME) 

BOUND_TO_TUPLES  (any, boolean, advance_upon) 

IN 

<I1.I:VT1,I2.l:VT2;E>{OPNAME(I1.l,I2.l)}<E,E;I1.l:VT1>, 


<I1:VT1,True:VT2;E>{OPNAME(I1.i,I2.i)}<E,E;I1.i:VT1>, 


<I1:VT„FaJse:VT2;E>(0PNAME(I1.i>Il2.i)}<I1.i,E;01.i-l> 

graphics:  draw_advance_upon_node; 

textual:  advance_upon(Il,I2);  (prefix-operation) 

} 
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concatenate_node 

{ 

names:  concatenate 
semantics: 

FOR.TUPLE  (VT,OPNAME) 
BOUND_TO  TUPLES  (any, concatenate) 
IN 


<I1:VT,I2:VT;E>{0PNAiME(I1,I2)}<E,E;01:VT> 

graphics:  draw_concatenate_node; 

textual:  concatenate^, I2);  (prefix-operation) 

} 


is_c  urrent_node 

{ 

names:  is_current 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO  TUPLES  (any,is_current) 
IN 


<I1.i:VT;E>{OPNAME(I1.i)}<E;I1.i:VT> 

graphics:  draw_is_current_node; 
textual:  is  current^);  (prefix-operation) 

} 


merge_node 

{ 

names:  merge 
semantics: 

FOR_TUPLE  (VT1,VTa,OPNAME) 
BOUND_TO_TUPLES  (bool, any, merge) 
IN 


<True:VT1,I2:VT2,E;E>(OPNAME(I1,I2,I3)}<E,E,E;I2:VT2>, 


<False:VT1,E,I3:\T3;E>{OPNAME(II,I2,l3)}<E,E,E:l3:VT2> 

graphics:  draw_merge_node; 
textual:  NONE 
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outbound_switch_node 

{ 

names:  outbound_switch 
semantics: 

FOR.TUPLE  (VTj.VT^OPNAME) 
BOUND_TO_TUPLES  (bool, any, outbound  switch) 
IN 


<Tnie:VT1,I2:VT2;E,E>{OPNAME(IllI2)}<E,E;I2:VT2,E>, 


<False:VT1,I2:VT2;E,E>{OPNAME(I1,I2)}<E,E;E,I2:VT2> 

graphics:  draw_outbound_switch_node; 
textual:  NONE 
} 


identity  _node 

{ 

names:  identity 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (any, identity) 

IN 

<Il:VT;E>{OPNAME(I1)}<E;I1.VT> 

graphics:  draw_identity_node; 
textual:  NONE 
} 


route_tokens_node 

{ 

names:  route_tokens 
semantics: 

FOR_TUPLE  (VT,,VT2,OPNAME) 

BOUND_TO_TUPLES  (any, int, route  tokens) 

IN 

(l<I2<n)  A  <Il:VTl,I2:VT2;El,  ,En>{OPNAME(I„I2)}<E,E;E1,  ,E^.„llrE^+1,  •••  ,En> 

graphics:  draw_route_tokens_node; 
textual:  NONE 
} 
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funnel  tokens_node 

{ 

names:  funnel_tokens 
semantics: 

FOR.TUPLE  (VTrVT2,OPNAME) 

BOUND_TO  TUPLES  (any,int,funnel_tokens) 

IN 

<I1:VT2,  .EIi_1,  Ii^VTj  ,EIi+1,...;E>{OPNAME(I1,  •  ■  •  ,!„}}<£,  E^VT^ 

graphics:  draw_funnel_tokens_node; 
textual:  NONE 
} 


apply_node 

{ 

names:  apply 
semantics: 

FOR_TUPLE  (VT1,VT2,OPNAME) 

BOUND_TO_TUPLES  (func tion ,any , apply ) 

IN 

<I1:VT„I8:VTj[ . I^VTjiE! . Em>{OPNAME(l1,...,I[1)}  <  E,E;0,:VT2 . Om:VT2> 

graphics:  draw_apply_node; 
textual:  applyfl,,^ . IJ  (apply-exp) 

} 


input_node 

{ 

names:  input 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO_TUPLES  (any,input) 
IN 


<;E>{OPNAME}<;0,:VT> 

graphics:  draw_input_node; 
textual:  NONE 

} 


output_node 

{ 

names:  output 
semantics: 

FOR_TUPLE  (VT,OPNAME) 

BOUND _TO_TUPLES  (any  .output) 

IN 

<  VT;  >  (OPNAMEfl,)}  <  E;  > 

graphics:  draw_output_node; 
textual:  NONE 
} 


constant_node 

{ 

names:  constant 
semantics: 

FOR_TUPLE  (VT.OPNAME) 
BOUND_TO_TUPLES  (any, constant) 
IN 


legal_constant(I2)  A  <I1:VT,I2:VT;E>  {OPNAMEfl,,^)}  <E,I2:VT;I2:VT> 

graphics:  draw_constant_node; 
textual:  NONE 
> 


fork_node 

{ 

names:  fork 
semantics: 

FOR_TUPLE  (VT.OPNAME) 

BOUND_TO_TUPLES  (any, fork) 

IN 

<I1:VT;E1...En>{OPNAME(I1)}<E;I1:VT,...,I1:VT> 

graphics:  draw_fork 
textual:  NONE 
} 
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if_then_else_node 

{ 

names:  if_then_else 
semantics: 

FOR_EACH(VT) 

BOUND_TO(int, real, bool, char,  array  .record, union, function) 

IN 

<I,:bool,  •  •  •  .I^VT In:VT;E„  ■  ■  ■  ,Em>  A  4  =  true  {S,}<E„  •  •  •  ,En;0,:VT Om.VT>, 

<li:bool,  •  •  •  .L^VT I0:VT;E„  ■  ■  •  ,Em>  A  4  =  false  {S4}<E1,  ■  ■  •  ,Eb;Oi:VT O^VT>, 

<I,:bool,4:VT . I0;E„  •  •  ■  ,Em>{lf  4  then  Si  else  S2}<E„  ■  •  •  ,En;0,:VT,  •  •  •  ,Om;VT> 

graphics:  draw_if_node; 
textual:  (conditional_expr) 

} 


begin_node 

{ 

names:  begin 
semantics: 

FOR_EACH(VT) 

BOUND_TO(int, real, bool, char, array, record, union, function) 

IN 

<Ai:VT,...,Ap:VT;E, . Em>  A  Ap  6  {{1, . 4}  U  {Ok}),l<n  on  ki 

{Sj}<E, . Ep;Oi:VT>  A  l<<n 

<I,:VT....,In:VT;E1 . Em>{begln  Si;S*...;Sk  end}<E, . E„;0,:VT, ..  ,Om>  A  0,0;  ,l<l<n 

graphics:  draw_begin_node; 
textual:  (begin_expr) 

} 


case_node 

{ 

names:  case 
semantics: 

F  OR_EACH(VT) 

BOUND_TO(int, real, bool, char,  array  .record, union, function) 

IN 

<  l1:VT,..!n:VT;E1 . Em>  {Sk+l}<E„...EI1;Oi:VT . Om:VT> , 

_ Is  Tj  x  A  <x  |  T|:VT,l1:VT,-ln:VT;E„...,Em><Ei,...Eg;Oi:VT . Om:VT> _ 

<I1:VT,In:VT;El,...,Em>{case  p:=x:union  of  T i:Si;...;Tk:SB;defauIt:Sk+1end}<E1,...En;01:VT . Om:VT> 

graphics:  draw_case_node; 
textual:  (case_expr) 

} 


! 


1 


130 


forall_eval_node 

{ 

names:  forall_eval 
semantics: 

FOR_EACH(VT) 

BOUND_TO(int, real, bool, char, array, record, union, function) 

IN 

<i:int,l1:VT . IB:VT;E1>{Sl}<El! . E0;Oi:VT>  A  (L<i<U), 

_ F  6  (plus, mult, and, or, min, max) _ 

Cln^VT . In„:VT;E>{forall  i  In  [L,U|  do  S,  eval:F}<E1,...,En;F(01,FiO2,...,F(0lH^Ou^+1)...))> 

graphics:  draw_forall_eval_node; 
textual:  (forall_expr) 

} 


forall _ construct_node 

{ 

names:  forall_construct 
semantics: 

FOR_EACH(VT) 

BO  UND_TO(int, real, bool, char, array, record, union, function) 

IN 

_ <i:int.li:VT,...,In:VT;E1>{S|}<E1 . En;Ol:VT>  A  (L<i<U), _ 

<ln,:VT . Inn:VT£> {forall  i  In  |L,U|  do  S,  construct) <E,,...,En;0:int-.VT> 

graphics:  draw_forall_construct_node ; 
textual:  (forall_expr) 

} 


for_iter_node 

{ 

names:  for_iter 
semantics: 

FOR_EACH(VT) 

BOUND_TO(int, real, bool, char, array, record, union  .function) 

IN 

<Inl.VT1,...,Ink:VTk;E1 . Ej>  A  (l<k,j<n){InUlaHze}<El,  •  ■  ,Ek;Oi:VT„  •  ■  rOj:VTj> 

-B  A  <Ini:VT„  ■  •  •  ,Inn:VTn;E,,  •  ■  •  ,Em>{S1}<In1:VT1,  •  •  ■  .In^VT^E,,  •  •  •  ,Em> 

_ B  A  <ln1:VT1,  •  •  •  .In^VTaiE,,  •  •  ■  ,Em>  A  (l<m<n){S8}<Ei,  ■  ■  •  ,En;Oi:VT„  •  ■  ,Om:VTm> _ 

<Ini:VT|,  •  ■  ■  ,InD:VTn;E,,...,Em>{for  initialize  do  If  B  then  S,  else  S2end}<E,,  •  •  ■  .En;0,:VT,,  ■  ■  ,Om:VTm> 

graphics:  draw_for_iter_node; 
textual:  (iteration_expr) 

} 
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ABSTRACT 


Several  converging  technologies  have  reached  the  point  where  they  can  be  integrated  and 
used  to  develop  an  advanced  programming  environment  for  writing  parallel  programs.  These 
technologies  include  advanced  graphics  workstations,  models  of  computation  which  can  be  used 
for  parallel  computation,  and  parallel  architectures  Several  manufacturers  are  providing  com¬ 
mercially  available  parallel  processing  computers  with  potential  for  satisfying  the  performance 
requirements  of  many  of  today’s  computing  problems.  Unfortunately,  these  computers  usually  do 
not  have  adequate,  user-friendly  programming  environments,  and  the  programming  primitives 
supported  by  each  machine  are  different.  Thus,  there  is  a  need  for  a  more  general ,  user-friendly 
programming  tool. 

The  dataflow  model  of  computation  has  been  receiving  increasing  attention  to  discover  the 
model’s  potential  use  in  parallel  programming-  Several  textual  languages  have  been  developed  for 
experimentation  with  parallel  programming.  Graphical  base  language  representations  have  been 
proposed,  but  not  developed  because  of  the  absence  of  graphics  technology  needed  to  implement 
graphical  languages.  The  potential  to  support  a  programming  language  which  permits  the  simul¬ 
taneous  existence  of  graphical  and  textual  representations  for  programs  has  become  practical  with 
recent  advances  in  interactive  graphics  technology  and  graphics  workstations. 

This  thesis  is  concerned  with  the  design  and  formal  specification  of  a  dataflow  programming 
language  which  supports  the  simultaneous  existence  of  graphical  and  textual  representations  for 
programs.  The  features  of  the  language  are  synthesized  from  existing  dataflow  languages.  The 
specification  combines  three  formal  specification  techniques  to  formally  specify  the  textual  syntax, 
graphical  representation,  and  semantics  of  the  language.  The  specification  serves  as  a  rigorous, 
unambiguous  description  of  the  language. 


